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