Den 26. sep. 2006 kl. 02.14 skrev Gav....:
In this case shouldn't the fallback be defined as a specific
language,
i.e. English. In which case the fallback should be
"ContractsMessages_en.xml" shouldn't it (as opposed to
"ContractMessages.xml").
Sounds like the best way, haven't tested Sjurs patches yet, but
hopefully
Then that wont mean having ?locale=en in the url for the default.
Actually, Ross' suggestion would require just that, although I am a
little unsure of the impact of the fact that en_US is defined as the
global default language. It could mean that for that special case you
would get the _en version without writing ?locale=en.
In the general case it works like this:
- when there's no locale match, the ContractsMessages.xml (without
_en) will be used
- if there is a locale match, the match will be used
- if there's no match and no default/fallback file (like
ContractsMessages.xml), the strings will be left untranslated
That means that in cases where the input strings (those to be
translated) are themselves perfect strings in one language (say,
English), *there's no need to do translation at all*. Which means
that all of the following files are superfluous:
- ContractsMessages_en.xml
- ContractsMessages_us.xml (the original, with misspelled locale)
- ContractsMessages.xml
That is, you can just delete it, and the strings will appear in
English if there's no match. The only benefit of having it there is
to serve as an example for new translations.
Beware that when the input strings are NOT human readable by most
people (like ISO 639 language codes), it is necessary to have at
least the fallback file to ensure that the input strings are always
translated into something understandable in some language.
Sjur
