Users first, no matter where they are

Recent syntax changes to L20n

Localizers and developers alike are instructed on some of L20n’s basic syntactic elements. Both can learn how these changes in syntax will affect L10n on each side of the fence. Since the examples provided below may be complicated for some localizers to fully understand, please contact Stas with any questions you have.

As L20n nears the 1.0 release, it matures as a programming language and a localization platform. The feature set stabilizes, and with it, the syntax gains its final form. In this post, I’d like to take some time to summarize the recent changes to L20n’s syntax and explain the rationale behind them.

Referencing entities and context variables

We noticed a need to distinguish between references to other entities and macros, defined in the localization files, and the context variables provided by the developer at run-time.

Consequently, we introduced the $ prefix to tell the context variables from other references. In the example below, notice how $numOpenTabs, whose value is given by the developer, is referenced by typing {{ $numOpenTab }}. On the other hand, brandName, which is another entity defined in the same file, is referenced via {{ brandName }}.

Default hash values

Another set of syntax changes makes L20n more robust by improving error recovery and reducing redundancy.

In the following code sample, note the asterisk prefix (*) for the nominative hash key. The prefix denotes a default value for the hash. If brandName is referenced without specifying a hash key, the value corresponding to the nominative key will be returned, thus guaranteeing that {{ brandName }} will resolve to a string.

Local entities and attributes

The last but not the least set of changes relate to the scope of entities, macros and attributes.

Assuming that the “regular” entities are all public (accessible by tools and the developers), L20n will also allow entities with a local scope, prefixed with an underscore (_).

These entities will only be visible to the localizers of the current locale. Developers will not be able to ask the L20n API for their values, and tools will not report on their status as compared to the source locale.

Localizers will be able to create local helper entities and macros, in order to improve consistency of translations and further reduce redundancy.

Consider the example below. By defining a local entity called _cancel, the localizer is able to abstract the translation of four other entities and store the related logic (the @os index) in a single place.