-
Notifications
You must be signed in to change notification settings - Fork 71
Language Selection
How to choose the appropriate locale, and how the l10n resource format should help.
<link rel="resource" type="application/l10n" href="data.properties" />
Requested features:
- we don’t want to specify the locale in the HTML document;
- we want to be able to add a locale without changing the HTML document;
- it should work without any web server (e.g. mobile app);
- the content JS should know which locales are available, and which locale has been selected.
That’s a trivial case: content negotiation ⇒ the web server sends a data.properties
file that best matches the browser prefs:
hello=Hello!
hello.accesskey=h
hello.title=click me
sayHello=Hello Mozilla!\nHello, world!
This can be achieved easily by grouping entities in [lang]
sections:
[*]
hello=Hello!
hello.accesskey=h
hello.title=click me
sayHello=Hello Mozilla!\nHello, world!
[fr]
hello=Bonjour !
hello.accesskey=b
hello.title=cliquez-moi !
sayHello=Bonjour Mozilla !\nBonjour, le monde !
[de]
hello=Hallo!
hello.accesskey=h
hello.title=hier clicken
sayHello=Hallo Mozilla!\nHallo, Welt!
A resource file can be used as an index, using @import
rules:
[*]
@import url("locales/data.en.properties")
[fr]
@import url("locales/data.fr.properties")
[de]
@import url("locales/data.de.properties")
Resource files can contain @import
rules and key/value pairs, e.g. to factorize the most common strings like OK/Cancel in a single file, and reuse this file in all resources.
It is possible to define an entity several times in the same resource file; in that case, the last definition replaces the former ones (pretty much like CSS rules).
This allows to work on locales by duplicating all lines from the main locale (usually English), as requested by the Mozilla l20n team:
[fr]
hello=Hello!
hello=Bonjour !
hello.accesskey=h
hello.accesskey=b
hello.title=click me
hello.title=cliquez-moi !
sayHello=Hello Mozilla!\nHello, world!
sayHello=Bonjour Mozilla !\nBonjour, le monde !
We don’t recommend doing this to translate your apps — just do what best suits your workflow!
It would be nice to have a way to say that an entity has been translated, but that the localized value is identical to the original one — for example, “OK” or most product names. Here’s what we’re thinking of…
This string is translated, but is identical to the original one:
[en-US]
okButton=OK
[fr]
okButton=OK
This string is untranslated (will default to the original one):
[en-US]
hello=Hello!
[fr]
hello=
The main drawback is that defining empty strings will be more difficult (e.g. a specific escape char will be required). Thoughts?