Skip to content
sonnyp edited this page Aug 10, 2012 · 8 revisions

How to choose the appropriate locale, and how the l10n resource format should help.

HTML Markup

    <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.

Use Cases

1. With a Web Server

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!

2. Client-side, single file

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!

3. Client-side, multiple files

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.

Unrelated

Overwritten entities

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!

Identical values

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?