Quasi-literals and localization

Mike Samuel mikesamuel at gmail.com
Thu Jul 12 00:20:37 PDT 2012

2012/7/2 Norbert Lindenberg <ecmascript at norbertlindenberg.com>:
> The quasi-literal proposal discusses at some length text localization [1]. After reading the section and then realizing that most of the discussed functionality is not actually part of the proposal, I'd like to ask that the discussion of localization in this context be removed.

The goal of the quasi-literal proposal is not to define any APIs for
localization but only to show that it could benefit a range of
localization proposals.

> 1) The discussion of the msg function is very incomplete with regards to the current state of the art in internationalized message construction. Modern message formatting libraries include support for plural and gender handling, which is not discussed here [2], and offer far more comprehensive number and date formatting than discussed here. The msg function also doesn't integrate with the ECMAScript Internationalization API [3].

Yep.  At the time the Quasi proposal was written, that was very much
in flux.  I chatted with Nebosja Ciric, Mark Davis and others last
March and they were planning on contributing to another proposal so I
just focused on explaining how a message extraction -> localization ->
message reintegration pipeline could work with messages in quasis, and
showing how the various concerns like l10n and security could compose.

> 2) Quasi-literals are based on the assumption that the pattern strings are normally embedded in the source code. In internationalization, that's called "hard-coded strings" and generally considered a really bad idea. Normally, you want to separate localizable text and data from the source code, so that localization can proceed and languages can be added without changes to the code. I'm aware that some companies are using a localization process that involves generating localized source files with embedded strings. This may be viable for web application where the code is hosted on a server and sent to the browser for execution each time the application is started. I don't see how it would work for applications that actually run on the server (e.g., within Node.js) and where the server has to provide localized responses in different languages for each request. I don't think it's viable either for applications that are made available through an application store (e.g., those buil
>  t with PhoneGap or Titanium) and which have to include support for multiple applications with minimal download size.

What about quasis makes dynamically choosing a message bundle based on
the locale of the current request and substituting for the source
language message particularly difficult?

> 3) The workaround discussed to support purely dynamic message replacement (which I'd consider the normal path from an internationalization point of view) seems to be duplicating much of the work involved in interpreting quasi-literals, but loses the variable names on the way, and doesn't permit passing through variables that aren't used in the original quasi-literal. The latter is necessary, for example, in the context of gender handling: Sentences may be gender dependent in some localized languages while not in the source language.

I'm a bit confused.  To which variable name are you referring?

> Regards,
> Norbert
> [1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis
> [2] https://docs.google.com/present/view?id=ddsrrpj5_68gkkvv6hs
> [3] http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list