Hey Richard, thanks for taking part in the discussion!
On Sat, Jul 18, 2015 at 2:33 PM, Richard Olsson <[email protected]> wrote:
>
> Personally what attracted me to L20n was the syntax, and not the
> integration with the web front-end stack. I think the original syntax works
> great, and although there are some minor tweaks in Stas's proposal that I
> wouldn't mind, I think Zibi has the more valid points on most issues begin
> discussed in this thread.
>
The thing that bothers me in the current syntax is how cryptic it is. Take
a look at this relatively simple example:
<unreadEmails[@cldr.plural($emailCount)] {
one: "You have one unread email",
other: "You have {{ $emailCount }} unread emails"
}>
There's all kinds of brackets in there, and three special characters: ., @
and $, and it's clear what they mean and how to even google them. Part of
this might actually be on purpose: having the dollar sigil in the
placeable might increase the chance of the localizer not translating the
variable name itself (I've seen this happen more than I wish I had :). But
that's just a hypothesis which we haven't verified.
Also, we keep talking about how the localizers will want to reference other
entities in translations, but do we have any other example of this other
than the {{ brandName }}?
I don't want localizers to do the following (which is redundant,
complicated and suffers from capitalization problems):
<_tab {
nominative: "tab",
genitive: "tab's"
}>
<closeTab "Close {{ _tab.nominative }}?">
<eraseTab "Erase all of this {{ _tab.genitive }} history?">
I want them to do the following:
<closeTab "Close tab?">
<eraseTab "Erase all of this tab's history?">
I've written about this before:
http://informationisart.com/20/
http://informationisart.com/19/
And I'm not sure if one of my examples (reproduced below) is what I want
the localizers to do anymore:
<_uniteDeMesure {
B: "o",
KB: "Ko",
MB: "Mo",
GB: "Go",
TB: "To"}><availableSize "Il reste {{ $size }} {{ _uniteDeMesure[$unit] }}">
We shouldn't be used hash value like that. Hash values should be a
collection of variants of the same entity depending on some external
variable, not data stores. I'm now thinking that we should offer a syntax
to dynamically reference entities by computed name and encourage localizers
to add many small private entities to their translation files:
<_unitB "o">
<_unitKB "Ko">
<_unitMB "Mo">
<_unitGB "Go">
<_unitTB "To">
<availableSize "Il reste {{ $size }} {{ @get('_unit' + $unit) }}">
The same i true for expressions and macros. What are the actual
use-cases? We might want to focus on advanced plurals support (including
animacy and personality) and some sort of string manipulation / lookup.
Also an easy way to select a specific branch of code form things like
@screen or @hour (hence my suggestion to add cond and condp, or a switch
statement).
If the desired syntax is too (technically) complex, making the parser
> heavier than is considered ideal for a browser app, why not pre-compile to
> a format that can be more easily parsed instead of changing the source
> syntax? The mo/po approach is actually one of the few things that I don't
> personally hate about gettext. :)
>
I think this is a valid point and we've been in fact doing this for a while
in Firefox OS already: all resource files are parsed and concatenated on
buildtime into JSONs.
One of the criteria for "webbiness" is the ability to do a F5-style
development, and any compile step prevents that. My hope is that we can
have parser that's fast enough to not be forced to use precompilation.
Maybe this is where my desire to have a lean syntax comes from :).
> This might seem a little bit off-topic, but it's part of a general way of
> thinking of L20n and the JS API as separate, which could actually affect
> some of the syntax questions. One example is the global @screen context,
> relevant in this discussion because of the @ prefix.
>
> I'm gonna go out on a limb here and say that I don't think globals should
> be in the language at all. While responsive localization is a great thing,
> the screen size should be a context provided by the browser JS API, and
> hence just be a normal $var. Most web localizers wouldn't know the
> difference, but it keeps the language cleaner and avoids taking on
> responsibilities which can prove to be very difficult, like how to deal
> with timezones for @hour (locale != timezone), or @screen when localizing
> on the back-end.
>
I like the idea of moving some (or all) globals into the $var space.
However, to address your point about some globals not being available in
certain environments, I'd like to point out that globals have always been
intended as platform- and environment-specific.
-stas
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
