| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We have been abusing the 'Language' field to store the language name
that appears in the GUI for a translation. But this field is officially
supposed to store the language code, and most tools that edit po file
set it automatically. This has caused the language being changed by
mistake in the paste.
There is a provision for custom fields with a name starting with 'X-'
though. So Now, if defined, it will use the custom 'X-Language-name'
field, and fall back to 'Language' in case that custom field is not defined.
This should prevent the language being lost when not careful while
editing the translation.
|
|
|
|
The last translation entry of a .po file was not properly handled.
|
|
|
|
This is mainly due to unhandled clang __has_featrure() buit-in.
I do not like this hack, but Coverity proved to be a very good tool for us.
|
|
|
|
Simply use pointers to the source and destination chars instead of multiple indices.
|
|
When the path does not contains a path separator (/ or \) the first
character of charset was skipped.
|
|
The charsets used by the translations now need to have a "$(name).cp" file,
which contains an charset index => unicode mapping. Otherwise
create_translations will fail.
|
|
|
