2012/7/2 Norbert Lindenberg <[email protected]>: > 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 bu il > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
