Hey Zibi, thanks for taking the time to write all of this down! I replied in the topic-specific threads with more details. Here I'll comment about the two other topics.
On Fri, Dec 16, 2016 at 9:47 AM, <[email protected]> wrote: > 2) Forward-compatible functions > > During concaptualization of how to make builtin functions forward compatible, > we identified that we cannot ensure that the contract between the provider of > the function and the localizer using it will be preserved. > One can imagine a builtin function like `PLATFORM()`, `OS()` or > `SCREEN_WIDTH()`, that will change its signature over time. > Same can be said for the environment in which the entity is being used. At > the time of creation of the entity, maybe just 2 platforms are considered, > but later the project target platforms may change. > > In such cases, additional bit of information allowing for better fallbacking > in case of such incompatibilities would be of high value to the quality of > the output. Can you specify what you mean by "better fallback" here? To my understanding, if a BUILTIN starts with 'foo' and 'bar' as possible values and we enforce a default value on variants, then the variants of the translation are exhaustive. Later, if a new value, 'baz', becomes available, the current translation still is exhaustive (with 'baz' resulting in the default variant). The localizer can improve the localization, but no extra fallback is needed. > 5) We don't seem to have a way to represent a combination of L20n and Intl > API using `formatToParts` feature. > > Although this did not come up in our prototyping yet, I believe that it is > the last moment to try to make space for such use case in our syntax. Do you think this should be solved in the syntax? The point of solving it in the syntax is to allow the localizer to control the formatting of each part. Instead, would it be enough to allow the developer to do it? It does seem like something related to the implementation of the UI. > a) "You have to pick up your package by December <b>2nd</b> 2016" > > ftl: > key = "You have to pick up your package by { $date }" > > js: > let date = new Date(); > ctx.formatValue('key', { > date: FTL.DateTime(date, {month: 'long', day: 'short', year: 'numeric'}) > }); formatToParts was designed with map() and reduce() in mind: dtf.formatToParts(date).map(({type, value}) => { switch (type) { case 'day': return `<b>${value}</b>`; default : return value; } }).reduce((string, part) => string + part); FTL arguments like FTL.DateTime could be instrumented to use formatToParts() instead of format() and would then require two functions as additional arguments. Here's an idea of what this could look like in JS: let date = new Date(); ctx.formatValue('key', { date: FTL.DateTime(date, {month: 'long', day: 'short', year: 'numeric'}).toParts(mapper, reducer) }); or maybe: FTL.DateTimeParts(date, {month: 'long', day: 'short', year: 'numeric'}, mapper, reducer) I don't have an opinion on either of these options yet, but the important part is -- is this enough? Or do we need to allow localizers to format individual parts somehow? I don't think we do, but I might be missing some use-cases. -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
