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.
Silences the clang warning:
static data member specialization of '_singleton' must
originally be declared in namespace 'Common'; accepted as a C++0x
extension [-Wc++0x-extensions]
Wrapping "namespace Common {}" around the macro assignment causes clang
to complain about a spurious semicolon, and removing the semicolon at
the end of the macro causes some editors to misbehave.
Changing the requirement of using the macro in one namespace (the
global) to another (Common) seems a small price to pay to
silence a warning.
Now if the header of the file is not correct it continues to look for a
valid file, while before if the first file found was obsolete or corrupted
translation was disabled even if a valid file was present in the search
path.
It was writing data beyond the end of a buffer. This change makes
sure this does not happen. It only changes reading of the messages
since the language codes, charset names and contexts are always
much smaller than the buffer.
- Broaden the range of language tags that could be accepted as fallback in
auto-detection. For example, for a system with locale 'pt_PT', all of
these would be accepted as valid fallbacks: 'pt_PT_*', 'pt', 'pt_*'
- Make language codes matching case-insensitive as specified in RFC 4647.
- Add support language code blocks longer than 2 characters.
svn-id: r54715
This makes it possible to write
DECLARE_SINGLETON(foo);
instead of
DECLARE_SINGLETON(foo)
without causing a warning about an extra semicolon.
The extra semicolon helps some editors at parsing the C++ code.
svn-id: r54258
Revision 54206 broke translations support because it uncovered a bug in
the TranslationManager when reading the translations.dat file. In that file
all the stored string lengths include the terminating 0 but Common::String
expect a length without the terminating 0. Therefore all String objects
created from reading the translations.dat file had an incorrect size. This
caused the font file names to be wrong after adding the charset.
svn-id: r54235
When switching to a theme that do not have the fonts needed to properly
display the current language, it now revert to the previously used theme
and display an error message telling the user to change the language
first if he wants to use the theme he selected.
svn-id: r52969
If the translations.dat file is not found using the SearchMan, it now looks
for that file into the themepath directory and sub-directories (if the path is
defined).
svn-id: r52428
This change means there can now be different translations for the same
english string depending on the context. It is based on gettext msgctxt feature.
There is a new macro _c(msg, ctxt) that should be used instead of _(msg) in
the source code when we want to add a context to the message. For the
moment I have added contexts to only one message ("None") so that I could
test the changes. Context could be added also to get shorter translations when
GUI is in 1x mode.
I have also added back the fuzzy option to msmerge since it is useful when
adding contexts to populate the translations for the new contexts.
svn-id: r52308
Previous commit of translation.cpp introduced a defined but not
implemented operator when the translation support was disabled.
This was probably fine since it was not used, but not very clean.
svn-id: r52241
This fix a regression introduced in revision 50448 ("Add support for
locale-dependant font'). When disabling localization a function was
declared, called but not implemented.
svn-id: r52048
The GUI now uses the content of the Language field from the po file
header if it is present and not empty for the language selection
PopupWidget. If not present it uses the file name as before (e.g.
ru_RU).
Also update all the translation template and all the translation files.
svn-id: r51542
Currently it ws not decided where to put fonts, but if you put BDF files into
themepath, they will get picked up.
The font name has to contain same codepage specification as in the .po file,
i.e. fixed5x8-iso-8859-5.bdf for Cyrillic codepage. In case the font does not
exist, default will be used.
All built in fonts get proper names.
TODO: Currently there is a bug with our font cacher. Font clR6x12-iso-8859-5
is empty after loading from FCC file. Reason is unknown.
svn-id: r50448
Note that this might break support for Windows versions older than Win2k,
at least according to the MSVC docs GetLocaleInfo is only supported by Win2k+.
I added a comment about that though.
svn-id: r50348
In recent discussions on -devel it turned out, that this
feature is rather superfluous and instead we should rather
implement a proper error reporting in our GUI.
I also removed the dependency on iconv along with this.
svn-id: r50335
