L20n/Features/Value ID

goal

enable defining ID as string/array/hash to emulate gettext-like key-value pair lists.

examples

This would enable gettext like workflow where the developer stores entity values directly in the source code wrapped in a function which turns the string into a key that is being matched in resource file with a localized value. If this is missing, the key itself (English string) is returned.

Proposed syntax:

<"Hello World" "Witaj Swiecie">

or, for multi lines:

<"""
Welcome to the new
<span>World</span>
"""

"""
Witaj w nowym
<span>swiecie</span>
""">

Such syntax is entirely possible and easy to add to LOL, but once we started evaluating how would it operate in conjunction with other L20n features it became obvious that we will have to basically strip all features of L20n in such case. Things get tricky when you go outside of the simple string example, and try to use complex strings (with expanders) or hashes as ids.

Expressions make no sense, indexes make no sense, macros will be useless. We also believe that even such simple features as plural forms for languages that use them would be impossible in such mode because for the string to be directly in the source code, the whole singular/plural structure would have to be stored in the source code and in every localizable resource, even for languages that do not have a concept of plurals, not to mention sentences with double-plural structures.

More examples:

_("Hello, World")

<"Hello, World" "Witaj świecie">

_("Hello, {{ username }}")

<"Hello, {{ username }}" "Witaj {{ username }}">

_({ one: "Hello, World", many: "Hello, Worlds" }, {n: 1})

<{ one: "Hello, World", many: "Hello, Worlds" }[plural(n)] 
 { one: "Witaj świecie", twofour: "Witajcie światy", many: "Witajcie, {{n}} światów" }>

In the last example, how do we know which macro to run 'n' through (plural)? Where is this macro defined for en-US?

We'd need to have two modes in L20n - full and "basic" which would just make it a container for key-value pairs plus placeables. That sounds unreasonable and would require us to provide the whole toolchain for a mode that will strip the localizer of the ability to work with the strings beyond what currently gettext offers.

In result we decided not to extend L20n with string based ID's for now, keeping the conversation going and waiting for suggestions.

We also believe that for rapid application development, where the developer does not have time to provide localization resources and prefers to just wrap his strings in a source code, an alternative, known as Common Pool, or pure Gettext is a better solution and we hope to see Common Pool and L20n live side by side with a transition from the former to the latter being automated as much as possible for the cases where the app grows to the point where the author begins to care about localizable UI.

That also means that we're voting against making the content localization one of top priorities for l20n. focusing on UI localization. For content localization technologies like Gettext or Common Pool are better suited.

status

• stas - against
• gandalf - torn
• pike - against