I have written the initial draft of a proposal for localization of HTML
pages in SDK-based addons:
https://github.com/mozilla/addon-sdk/wiki/HTML-Page-Localization
The proposal intends to build on and complement the existing work on
localization and provide a simple mechanism for addons to localize
static and dynamic text in their pages.
Please take a look, and let me know what you think!
I'm particularly interested in feedback from folks who use template
processors like jQuery Templates or mustache.js in addon pages, as I
want to minimize conflicts with such processors to enable the broadest
possible use of popular JS libraries alongside localization in addon pages.
-myk
This doesn't seem terrible however, considering that underscore.js has
functionality built-in to work around naming conflicts.
Jeff
> --
> You received this message because you are subscribed to the Google Groups
> "mozilla-labs-jetpack" group.
> To post to this group, send email to mozilla-la...@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs-jet...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
>
That looks excellent, particularly regarding the static processing functionality. My only concern would be that the use of the gettext-ish '_' character might complicate use of the underscore.js Javascript library. This doesn't seem terrible however, considering that underscore.js has functionality built-in to work around naming conflicts.
- One way to fix conflicts with web framework translation would be to give a void to disable this l10n parsing.
Don't you think we should have a specific protocol for localization?
Or a pattern in addon:// URLS to enable/disable localization parser?
- Do you consider using "gettext" pattern in static localization. i.e accept localized strings in the template. So that an HTML page can be localizable without having to create any properties file and match same features/behavior than dynamic API?
Something like: <head>${Simple page}</head> (Needs a rule to escape key delimiter, here `}`)
- References within references. It is a great idea and it should be part of the common code between content and addon main l10n modules!
- So if I got it correctly, what you are describing in second paragraph "dynamic localization" is part of non-goals? It would be clearer if you remove this non-goals note and put a comment in this paragraph.
document.body.appendChild(_("Hello, World!"));But not this:
document.body.innerHTML = _("<p>${helloWorld}</p>");
- Currently, there is only one big property file. Do you think we will need more than one for the use of static localization?
I have some concerns with the existing pattern about:
* code sharing (being able to share a piece of code with its related properties)
* keys conflicts (if two static files use the same key)
- Do you think we will be able to automatically fetch keys used for static localization with cfx?
Would it be reasonnable to fetch all ${.*} patterns in all html files from data folder?
Same question applies to dynamic localization. My main concern is that I'd really like to implement a feature that will automatically build the list of all used `keys`!
<html>
<head>
<title data-l10n>title</title>
</head>
<body data-l10n>
Hello <span data-l10n>world</span>
</body>
</html>
where “demo/data.properties” is the default l10n resource (fallback), and translation files use a [.lang] suffix — e.g. demo/data.properties.fr for the French translation. That’s the simplest solution I could think of, but I’m open to suggestions here (and I’d like to have a more explicit “rel” attribute).<link rel="resource" type="text/l10n" href="demo/data.properties" />
+1
> 2. I do not particularly mind `${key}` approach, but I think it may
> have same / bigger conflict implications as mustaches `{{key}}`, since
> ES.next uses them for quasi
> literals: http://wiki.ecmascript.org/doku.php?id=harmony:quasis
It isn't clear to me that quasi-literals will show up in the same places
these keys will, but in any case the delimiter can be anything, so we
could surely find a non-conflicting one.
> Also, I do like slightly modified third alternative in the proposal:
...
> Elements that have `data-l10n` attribute set will have their innerHTML
> replaced with localized version and existing innerHTML will be used as
> keys (Note support for the nesting). In the future data-l10n attribute
> value may be used to provide additional information for localization
> similar to l10n.get. This solution avoids all the conflicts with
> existing / future js libs and feels more htmly to me.
An approach like this runs into the problem that it isn't possible to
trigger localization at parse time, so it must instead do so after
parsing is completed, as the l20n examples do, perhaps hiding content
until localization is complete to avoid a flicker effect as
non-localized content becomes localized.
The template-like approach also seems more webby to me, even if it is
less HTMLy. ;-)
Nevertheless, the l20n folks do raise valid concerns about the ease of
performing localization with a template-like approach. It isn't clear to
me that those concerns are unresolvable, but I'm certainly open to an
attribute-based approach. Note that such an approach should allow
localization of attribute values in addition to node descendants, i.e.:
<a title="localize me too">localize me</a>
In any case, Alex has expressed an interest in driving this proposal
forward, so I'll let him decide how to evolve it given the latest round
of feedback!
-myk
>> - References within references. It is a great idea and it should be
>> part of the common code between content and addon main l10n modules!
> Yes, good idea!
I thought was a good idea too when I did my localization code in my
previous jobs. However, it was proved that it was good just because I
looked at it with developer's eyes. Working side by side with pure
translator - no any kind of developers skill � proved that for them was
hard to follow nested references. Also, nested reference already
included some assumption about how the sentence should be translated, we
implicit assume it will contains that specific "term". Maybe that could
be true in latin-like languages, but not in all of them. In some cases,
it was just better re-phrase.
So, I was thinking that having a "nested reference" to the time unit in
was good, but it was actually better duplicated the terms.
At the end I had to disable that feature.
So, I'm not sure who we're going to target � developers? Translators? �
neither which languages, but I will be very careful to add and push this
option. It could be easily end up in a mess for translators.
Of course, all I said is limited to my personal experience.
I guess it depends on how far you take it. If you get all excited about
it and try to use it in your logic, it produces the problems you described.
However, I found the ability to nest references invaluable for branding.
Often, the brand name appears in the string. In earlier Mozilla times,
DTDs didn't support nesting, which meant that these strings with a brand
had to use .properties and be manually set from a script. Extremely
painful. Now that I can just say "Thanks for using &brandname;", this is
no problem anymore and I have less fights with the Product Manager. ;-)
Ben
>>>> - References within references. It is a great idea and it should be
>>>> part of the common code between content and addon main l10n modules!
>>> Yes, good idea!
>> I thought was a good idea too when I did my localization code in my
>> previous jobs. However, it was proved that it was good just because I
>> looked at it with developer's eyes. Working side by side with pure
>> translator - no any kind of developers skill � proved that for them was
>> hard to follow nested references. Also, nested reference already
>> included some assumption about how the sentence should be translated, we
>> implicit assume it will contains that specific "term". Maybe that could
>> be true in latin-like languages, but not in all of them. In some cases,
>> it was just better re-phrase.
>> So, I was thinking that having a "nested reference" to the time unit in
>> was good, but it was actually better duplicated the terms.
>>
>> At the end I had to disable that feature.
>> So, I'm not sure who we're going to target � developers? Translators? �
>> neither which languages, but I will be very careful to add and push this
>> option. It could be easily end up in a mess for translators.
>>
>> Of course, all I said is limited to my personal experience.
>
> I guess it depends on how far you take it. If you get all excited about
> it and try to use it in your logic, it produces the problems you described.
>
> However, I found the ability to nest references invaluable for branding.
Branding was probably the only case where I didn't have the problem I
described. It's pretty unique. But in most of the case the translator
didn't have the visibility of the whole file as you have as developer.
Usually the sentences were imported is some Translator tool (via DITA
files) so what they saw was just the sentence they're going to
translate. Having cross reference inside makes the things messier for
them, because they can't see what &open.label; or &time.unit; really
means, and they also could have different meaning depends by the context
or language.
As developer I agree that nesting references looks great and less
painful. But from a translators point of view could be different. Of
course I don't say that we shouldn't have this feature: I just wanted to
share my personal experience about some dangers that could be bring if
abused, especially if we're targeting translators (and translator tools)
as well, and not just developers.
Branding was the only case (that I remember) where I used nested refs,
yes. I do have several brand labels, though, not just one, e.g.
"Mozilla", "Mozilla Seamonkey", "Mail and news" (long), "Mailnews"
(short), "Composer" etc, all in one app.
Almost all other cases where you construct sentences might be useful for
a programmer, but are too dangerous from a linguistic standpoint,
because the sentence or words (common or weird forms of conjugation)
change in some languages. That is why translators tell us to always use
whole sentences. It's not because they don't understand (well, not
only), but because the languages are so widely different.
> Almost all other cases where you construct sentences might be useful for
> a programmer, but are too dangerous from a linguistic standpoint,
> because the sentence or words (common or weird forms of conjugation)
> change in some languages. That is why translators tell us to always use
> whole sentences. It's not because they don't understand (well, not
> only), but because the languages are so widely different.
Exactly, as I described in my first post. I added also the limitation of
the tool / context because I remember it during the reply. :)
parsing is completed:
You can find an overall description on the wiki:
https://github.com/mozilla/addon-sdk/wiki/HTML-Page-Localization
And look at the possible implementation here:
https://github.com/mozilla/addon-sdk/pull/387
Some alternatives/possible-improvements are listed on the wiki.
Any feedback is welcomed!
2012/3/21 Dave Townsend <dtow...@oxymoronical.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "mozilla-labs-jetpack" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mozilla-labs-jetpack/-/Jc-YQjf8tiQJ.
<p>When you visit <a class="domain"></a>, it informs the following websites about you.</p>Currently you can only inject text content from properties files, so that you will have to split this html in pieces into:
<p><span data-l10n-id="descRefereeStart">When you visit</span> <a class="domain"></a>, <span data-l10n-id="descRefereeEnd">it informs the following websites about you.</span></p>From localization perspective it is awfull and may disallow translating in some languages or only with weird sentences.
descRefereeStart = When you visit
descRefereeEnd = it informs the following websites about you.
<p data-l10n-id="descRefereeStart">When you visit <a class="domain"></a>, it informs the following websites about you.</p>I'd like to synchronize this work with Gaia and l20n projects in order to try ending up with a similar feature/implementation.
descReferee = When you visit <a></a>, it informs the following websites about you.