localizing Add-on SDK-based Firefox features

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

localizing Add-on SDK-based Firefox features

Myk Melez
Localizers!

I recently started the Jetpack Features working group [1] to investigate
the feasibility of shipping core Firefox features as default addons
built with the Add-on SDK (similar to the way the Test Pilot addon ships
with Firefox beta builds), with an initial focus on the BrowserID, Open
Web Apps, and F1 Sharing features.

One of our challenges is figuring out how to localize these features,
which embed strings in JavaScript code and also load HTML pages (but do
not use XUL).

Jetpack engineer Alex Poirot is working on a localization API for the
SDK that should eventually be the best method for localizing the
features, but I want to make sure it's possible to localize them even
before that API is ready, since two of the feature teams want to ship
their features soon (in Q1 of next year, I think).

For strings embedded in JavaScript, it seems like we could do the same
thing we did for the Test Pilot addon: land .properties files containing
the strings into the mozilla-central repository, use the existing
localization process for localizing them, and then have the SDK-based
addons access them via the XPCOM API.

I'm not familiar with the existing process for localizing HTML pages,
though. And presumably it's designed to localize web pages hosted on a
server, whereas these features are mostly (entirely?) bundling their
pages inside the addon packages.

How do we currently localize web pages? And what do y'all think would be
the simplest/best solution for localizing these pages bundled with
default addons?

-myk

[1] https://wiki.mozilla.org/Jetpack/Features

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Matjaz Horvat-2
Hi Myk,

We mainly use two different approaches for web localization:

1. Pootle (https://localize.mozilla.org/)
- For projects like AMO, Firefox Input, Mozillians, Webify Me

2. Plain HTML/PHP files
- Mostly mozilla.com

However, for this particular example we could try out Pontoon [1], in-place
website localization tool. I'll be talking about it at the EU MozCamp in
Berlin this weeked and if anyone from your team is coming, I'd love to chat
about using Pontoon for localizing Add-on SDK-based Firefox features.

-Matjaž

[1] http://horv.at/pontoon/

On Wed, Nov 9, 2011 at 9:11 PM, Myk Melez <[hidden email]> wrote:

> Localizers!
>
> I recently started the Jetpack Features working group [1] to investigate
> the feasibility of shipping core Firefox features as default addons built
> with the Add-on SDK (similar to the way the Test Pilot addon ships with
> Firefox beta builds), with an initial focus on the BrowserID, Open Web
> Apps, and F1 Sharing features.
>
> One of our challenges is figuring out how to localize these features,
> which embed strings in JavaScript code and also load HTML pages (but do not
> use XUL).
>
> Jetpack engineer Alex Poirot is working on a localization API for the SDK
> that should eventually be the best method for localizing the features, but
> I want to make sure it's possible to localize them even before that API is
> ready, since two of the feature teams want to ship their features soon (in
> Q1 of next year, I think).
>
> For strings embedded in JavaScript, it seems like we could do the same
> thing we did for the Test Pilot addon: land .properties files containing
> the strings into the mozilla-central repository, use the existing
> localization process for localizing them, and then have the SDK-based
> addons access them via the XPCOM API.
>
> I'm not familiar with the existing process for localizing HTML pages,
> though. And presumably it's designed to localize web pages hosted on a
> server, whereas these features are mostly (entirely?) bundling their pages
> inside the addon packages.
>
> How do we currently localize web pages? And what do y'all think would be
> the simplest/best solution for localizing these pages bundled with default
> addons?
>
> -myk
>
> [1] https://wiki.mozilla.org/**Jetpack/Features<https://wiki.mozilla.org/Jetpack/Features>
>
> ______________________________**_________________
> dev-l10n mailing list
> [hidden email]
> https://lists.mozilla.org/**listinfo/dev-l10n<https://lists.mozilla.org/listinfo/dev-l10n>
>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Myk Melez
On 2011-11-09 1:22 PM, Matjaz Horvat wrote:
> However, for this particular example we could try out Pontoon [1],
> in-place website localization tool. I'll be talking about it at the EU
> MozCamp in Berlin this weeked and if anyone from your team is coming,
> I'd love to chat about using Pontoon for localizing Add-on SDK-based
> Firefox features.
Hi Matjaž,

Several members of the Jetpack team will be at MozCamp, including (I
think) Technical Evangelist Jeff Griffiths and Software Engineer
Alexandre Poirot. They'll be great resources for talking about addon
localization generally. However, the Jetpack Features working group is
mostly a separate effort from the main Jetpack project, so they might
not be familiar with it.

I'm hoping to identify the least-experimental solution for localizing
these features, to reduce schedule risk, so I'm a little wary of trying
something new that localizers aren't already using. But if there isn't a
suitable existing tool, then a new one is certainly an option!

So I just tried Pontoon, which looks quite simple and usable.

One question is whether localized strings are loaded directly from the
Pontoon server, which would introduce a problematic network dependency,
or copied to the location of the web page and loaded from there.

More importantly, though, I'm not sure how to apply such a tool to a web
page that isn't being served by a server but rather is stored in an
addon package bundled with Firefox and loaded from the filesystem. We
might be able to add the necessary <script> tag to those pages (at least
during the localization process, although we'd probably want to remove
it from the shipping version), but what URL would one type into the URL
field in Pontoon's home screen in order to display and localize the pages?

The web pages in these features are a lot more like XUL documents in
Firefox than HTML pages on websites. So I suspect that the best process
in this case will be one that looks a lot like the way XUL in Firefox is
localized, except that the markup language will be HTML.

-myk

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Rimas Kudelis-4
In reply to this post by Myk Melez
Hi Myk,

2011.11.09 22:11, Myk Melez rašė:
> I'm not familiar with the existing process for localizing HTML pages,
> though. And presumably it's designed to localize web pages hosted on a
> server, whereas these features are mostly (entirely?) bundling their
> pages inside the addon packages.
>
> How do we currently localize web pages? And what do y'all think would be
> the simplest/best solution for localizing these pages bundled with
> default addons?


Here's a tip: open Firefox, go to about:home and view source. You'll get
the idea: we're currently using DTD files to localize strings and
reference those strings directly from HTML. It seems to work fine so far. :)

Hope this helps,
Rimas
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Myk Melez
On 2011-11-09 10:41 PM, Rimas Kudelis wrote:
> Here's a tip: open Firefox, go to about:home and view source. You'll get
> the idea: we're currently using DTD files to localize strings and
> reference those strings directly from HTML. It seems to work fine so far. :)
Ah, right, that seems like a good short-term solution for localizing
SDK-based features as well.

Thanks Rimas!

-myk

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Ehsan Akhgari
In reply to this post by Myk Melez
Sorry, typing on a phone makes you forget half of what you wanted to say.

The gotcha about using HTML entities is that our XML parser is capable of
handling them, which means that the content should be valid XHTML, which
means that it is affected by the cumbersome syntax of XHTML and also some
of the limitations that XHTML has compared to HTML5.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>


On Thu, Nov 10, 2011 at 12:30 PM, Myk Melez <[hidden email]> wrote:

>  On 2011-11-09 8:25 PM, Ehsan Akhgari wrote:
>
> The HTML pages used in Firefox are localized using HTML entities alongside
> dtd files. I believe that's much simpler than editing HTML markup, which is
> what our localizers go through currently when tranlating mozilla.orgpages.
>
> Hmm, indeed, I bet we can use this to localize SDK-based features.
>
> Thanks Ehsan!
>
> -myk
>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Myk Melez
On 2011-11-10 11:08 AM, Ehsan Akhgari wrote:
> Sorry, typing on a phone makes you forget half of what you wanted to say.
>
> The gotcha about using HTML entities is that our XML parser is capable
> of handling them, which means that the content should be valid XHTML,
> which means that it is affected by the cumbersome syntax of XHTML and
> also some of the limitations that XHTML has compared to HTML5.
Hmm, that might be a problem. I'll check with the folks developing these
pages.

-myk

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Rimas Kudelis
In reply to this post by Ehsan Akhgari
2011.11.11 00:58, Myk Melez rašė:
> On 2011-11-10 11:08 AM, Ehsan Akhgari wrote:
>> Sorry, typing on a phone makes you forget half of what you wanted to say.
>>
>> The gotcha about using HTML entities is that our XML parser is capable
>> of handling them, which means that the content should be valid XHTML,
>> which means that it is affected by the cumbersome syntax of XHTML and
>> also some of the limitations that XHTML has compared to HTML5.
> Hmm, that might be a problem. I'll check with the folks developing these
> pages.

This makes me wonder, what can be problematic about writing XHTML?
Closing <p></p> and <br/> tags? IMO, it's not cumbersome, it's just
strict. And how is XHTML5 limited compared to HTML5? I just don't get it...

Rimas
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Ehsan Akhgari
On Fri, Nov 11, 2011 at 4:32 AM, Rimas Kudelis <[hidden email]> wrote:

> 2011.11.11 00:58, Myk Melez rašė:
>
>> On 2011-11-10 11:08 AM, Ehsan Akhgari wrote:
>>
>>> Sorry, typing on a phone makes you forget half of what you wanted to say.
>>>
>>> The gotcha about using HTML entities is that our XML parser is capable
>>> of handling them, which means that the content should be valid XHTML,
>>> which means that it is affected by the cumbersome syntax of XHTML and
>>> also some of the limitations that XHTML has compared to HTML5.
>>>
>> Hmm, that might be a problem. I'll check with the folks developing these
>> pages.
>>
>
> This makes me wonder, what can be problematic about writing XHTML? Closing
> <p></p> and <br/> tags? IMO, it's not cumbersome, it's just strict. And how
> is XHTML5 limited compared to HTML5? I just don't get it...
>

Please see this document for a list of some of those differences: <
http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_and_XHTML
>

Also, XHTML5 is not supported by Gecko at all (and for that matter, by any
other browser engine that I know of), but because the HTML5 parser is
forgiving, most of the so-called XHTML5 content will work just fine by any
HTML5 compliant engine.

--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Rimas Kudelis-4
In reply to this post by Rimas Kudelis
Hi Ehsan,

2011.11.11 21:34, Ehsan Akhgari rašė:

> On Fri, Nov 11, 2011 at 4:32 AM, Rimas Kudelis <[hidden email]> wrote:
>
>> 2011.11.11 00:58, Myk Melez rašė:
>>
>>> On 2011-11-10 11:08 AM, Ehsan Akhgari wrote:
>>>
>>>> Sorry, typing on a phone makes you forget half of what you wanted to say.
>>>>
>>>> The gotcha about using HTML entities is that our XML parser is capable
>>>> of handling them, which means that the content should be valid XHTML,
>>>> which means that it is affected by the cumbersome syntax of XHTML and
>>>> also some of the limitations that XHTML has compared to HTML5.
>>>>
>>> Hmm, that might be a problem. I'll check with the folks developing these
>>> pages.
>>>
>>
>> This makes me wonder, what can be problematic about writing XHTML? Closing
>> <p></p> and <br/> tags? IMO, it's not cumbersome, it's just strict. And how
>> is XHTML5 limited compared to HTML5? I just don't get it...
>>
>
> Please see this document for a list of some of those differences: <
> http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_and_XHTML

Just read it all. I don't think there's anything scary there. It mostly
talks about a bunch o edge cases I would say we aren't very likely to
ever stumble on (and which can be easily avoided for built-in static pages).

About the only gotcha, that is really relevant in this situation, is the
'Entity References' feature, which, like you said, is only supported in
XHTML mode.

> Also, XHTML5 is not supported by Gecko at all (and for that matter, by any
> other browser engine that I know of), but because the HTML5 parser is
> forgiving, most of the so-called XHTML5 content will work just fine by any
> HTML5 compliant engine.

Well, don't we already have an XHTML5 (XML) parser? I wonder how hard it
would be to add the rest of support for proper XHTML5 into Gecko. I'm
probably wrong, but to me it seems like perhaps the only part that can
be missing is the support for new HTML5 elements in XML mode, no?

Rimas
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Ehsan Akhgari
On Sat, Nov 12, 2011 at 4:26 PM, Rimas Kudelis <[hidden email]> wrote:

> Hi Ehsan,
>
> 2011.11.11 21:34, Ehsan Akhgari rašė:
> > On Fri, Nov 11, 2011 at 4:32 AM, Rimas Kudelis <[hidden email]> wrote:
> >
> >> 2011.11.11 00:58, Myk Melez rašė:
> >>
> >>> On 2011-11-10 11:08 AM, Ehsan Akhgari wrote:
> >>>
> >>>> Sorry, typing on a phone makes you forget half of what you wanted to
> say.
> >>>>
> >>>> The gotcha about using HTML entities is that our XML parser is capable
> >>>> of handling them, which means that the content should be valid XHTML,
> >>>> which means that it is affected by the cumbersome syntax of XHTML and
> >>>> also some of the limitations that XHTML has compared to HTML5.
> >>>>
> >>> Hmm, that might be a problem. I'll check with the folks developing
> these
> >>> pages.
> >>>
> >>
> >> This makes me wonder, what can be problematic about writing XHTML?
> Closing
> >> <p></p> and <br/> tags? IMO, it's not cumbersome, it's just strict. And
> how
> >> is XHTML5 limited compared to HTML5? I just don't get it...
> >>
> >
> > Please see this document for a list of some of those differences: <
> >
> http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_and_XHTML
>
> Just read it all. I don't think there's anything scary there. It mostly
> talks about a bunch o edge cases I would say we aren't very likely to
> ever stumble on (and which can be easily avoided for built-in static
> pages).
>
> About the only gotcha, that is really relevant in this situation, is the
> 'Entity References' feature, which, like you said, is only supported in
> XHTML mode.
>

I agree that there is nothing scary there, it's just something that the
engineers working on this feature need to be aware of, which is why I
mentioned this.


>  > Also, XHTML5 is not supported by Gecko at all (and for that matter, by
> any
> > other browser engine that I know of), but because the HTML5 parser is
> > forgiving, most of the so-called XHTML5 content will work just fine by
> any
> > HTML5 compliant engine.
>
> Well, don't we already have an XHTML5 (XML) parser? I wonder how hard it
> would be to add the rest of support for proper XHTML5 into Gecko. I'm
> probably wrong, but to me it seems like perhaps the only part that can
> be missing is the support for new HTML5 elements in XML mode, no?
>

This is off-topic for this thread.  Please ask this question on
dev.platform if you're really interested in discussing this.  Thanks!

--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

davidascher
In reply to this post by Matjaz Horvat-2
My own take is that HTML5 is the future that we're assuming everywhere (features, browser support, etc.), and we should figure out what it'll take to localize HMTL5 pages.  On the server, that's a non-issue, with a lot of techniques available.  On the client, what are the downsides to using a JS library to read .properties files and do DOM manipulation, rather than rely on the not-so-standard use of DTDs & XHTML?  (In particular, the more we can standardize on HTML5 & JS, the more wide the possible environment, including non-gecko environments).  Ten years ago, I vaguely remember people talking about DTDs&XHTML being faster than JS-based approaches, but much has changed since then, and I wouldn't bet against JS & HTML5 today...

--david
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Myk Melez-3
On 2011-11-14 1:10 PM, [hidden email] wrote:
> My own take is that HTML5 is the future that we're assuming everywhere (features, browser support, etc.), and we should figure out what it'll take to localize HMTL5 pages.  On the server, that's a non-issue, with a lot of techniques available.  On the client, what are the downsides to using a JS library to read .properties files and do DOM manipulation, rather than rely on the not-so-standard use of DTDs&  XHTML?
Except for the time required to write that .properties file parser and
DOM manipulator, that seems like a reasonable solution to me. It allows
localizers to use existing tools and processes to localize strings in
.properties files while enabling feature developers to continue to use
HTML5 to build their application interfaces.

> (In particular, the more we can standardize on HTML5&  JS, the more wide the possible environment, including non-gecko environments).  Ten years ago, I vaguely remember people talking about DTDs&XHTML being faster than JS-based approaches, but much has changed since then, and I wouldn't bet against JS&  HTML5 today...
Also keep in mind that HTML5/JS doesn't have to be faster than
XHTML/DTD, it just has to be fast enough to meet user expectations of a
performant interface.

-myk

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Ehsan Akhgari
On Mon, Nov 14, 2011 at 5:17 PM, Myk Melez <[hidden email]> wrote:

> On 2011-11-14 1:10 PM, [hidden email] wrote:
>
>> My own take is that HTML5 is the future that we're assuming everywhere
>> (features, browser support, etc.), and we should figure out what it'll take
>> to localize HMTL5 pages.  On the server, that's a non-issue, with a lot of
>> techniques available.  On the client, what are the downsides to using a JS
>> library to read .properties files and do DOM manipulation, rather than rely
>> on the not-so-standard use of DTDs&  XHTML?
>>
> Except for the time required to write that .properties file parser and DOM
> manipulator, that seems like a reasonable solution to me. It allows
> localizers to use existing tools and processes to localize strings in
> .properties files while enabling feature developers to continue to use
> HTML5 to build their application interfaces.
>

The code to parse the properties files already exists in the platform.  See
nsIStringBundle and friends.

The code to apply the replacements to HTML5 documents would be way more
involved, though.  To keep things compatible with the existing XHTML-based
localization support in the platform, this needs to happen before/as the
HTML5 parser parses the document.  Henri is the person to ask about this.

Also, there has been talk about the next generation of l10n facilities in
form of the L20n project.  I think if you're planning on implementing a new
l10n solution, you should talk to Axel/Stas about how far along those plans
are these days.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Robert Kaiser
In reply to this post by Myk Melez-3
Ehsan Akhgari schrieb:
> Also, there has been talk about the next generation of l10n facilities in
> form of the L20n project.  I think if you're planning on implementing a new
> l10n solution, you should talk to Axel/Stas about how far along those plans
> are these days.

Actually, gandalf is working on that, AFAIK. And the mechanisms to hook
it into XUL are made in a way that keep in mind that it can be done
similarly for HTML as well, IIRC.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Myk Melez-3
In reply to this post by Ehsan Akhgari
On 2011-11-14 17:36, Ehsan Akhgari wrote:
> The code to parse the properties files already exists in the
> platform.  See nsIStringBundle and friends.
Ah, of course! We should be able to reuse that implementation.

> The code to apply the replacements to HTML5 documents would be way
> more involved, though.  To keep things compatible with the existing
> XHTML-based localization support in the platform, this needs to happen
> before/as the HTML5 parser parses the document.  Henri is the person
> to ask about this.
I don't see a reason to maintain compatibility with the XHTML-based
localization support. My goal is to enable the presentation of localized
pages to users while allowing localizers to provide localizations for
those pages via a process that is familiar to them (i.e. .properties
files checked into mozilla-central).

But perhaps I just misunderstand. What kind of compatibility are you
thinking of?

> Also, there has been talk about the next generation of l10n facilities
> in form of the L20n project.  I think if you're planning on
> implementing a new l10n solution, you should talk to Axel/Stas about
> how far along those plans are these days.
I'm not planning to implement a new l10n solution. The Jetpack project
is planning to do that for addons generally in the medium term, but my
goal here is just to implement a stopgap measure that enables us to ship
localized features with Firefox in the short term.

-myk

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Ehsan Akhgari
On Tue, Nov 15, 2011 at 11:31 AM, Myk Melez <[hidden email]> wrote:

>  The code to apply the replacements to HTML5 documents would be way more
>> involved, though.  To keep things compatible with the existing XHTML-based
>> localization support in the platform, this needs to happen before/as the
>> HTML5 parser parses the document.  Henri is the person to ask about this.
>>
> I don't see a reason to maintain compatibility with the XHTML-based
> localization support. My goal is to enable the presentation of localized
> pages to users while allowing localizers to provide localizations for those
> pages via a process that is familiar to them (i.e. .properties files
> checked into mozilla-central).
>
> But perhaps I just misunderstand. What kind of compatibility are you
> thinking of?


Consider the following HTML document for example:

<script>
  alert("&hello; Jetpack!");
</script>

Replacing the hello entity after the document has been parsed would be too
late in this case, because the side-effects of the script execution have
already happened by that point.  Whereas currently the hello entity would
be replaced by the XML parser with the corresponding localized string as
the document is being parsed, so the script will get executed with the
localized string as the document is being parsed.

Other examples that come to my mind are using entities inside attribute
values, for example:

<div dir="&locale.dir;">
  foo bar
</div>

In this case, replacing the dir attribute on the div after the document has
been parsed _could_ potentially have a visual side effect (the direction of
the paragraph being changed) for RTL locales which would define locale.dir
to be "rtl" for example.

Note that I'm not advocating for one solution over the other.  I just
wanted to point out that "simulating" the existing entity-replacement based
l10n technique for XHTML in HTML5 would potentially be hard.  This is not
so much of a concern for localizers (because they're already familiar with
the other way of localizing strings, namely editing properties files) as it
is a concern for people who are going to write localizable add-ons, in that
they should be aware that writing an HTML files with entities inside them
and putting the definitions of those entities in a properties file is going
to much different semantics than using entities in traditional add-ons.


Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Myk Melez-3
On 2011-11-15 08:56, Ehsan Akhgari wrote:
> Note that I'm not advocating for one solution over the other.  I just
> wanted to point out that "simulating" the existing entity-replacement
> based l10n technique for XHTML in HTML5 would potentially be hard.
Yup, point well taken. Fortunately, our goal in this case is just to
support localization of the pages for a specific set of features, not to
simulate the existing technique for localizing XUL/XHTML, nor even to
support localization of addon pages generally.

So if one of the features needs to `alert()` or to insert a localized
string into a DOM attribute at parse time, then supporting that behavior
will be a requirement for whatever we come up with. But otherwise, it
won't, as this is very much about coming up with the minimal fix that
unblocks us while we wait for the better medium-term solution.

-myk

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

davidascher
Right, my thought was to strictly use property files, and not entity
references, for this scope of add-on SDK-based features.

-da

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: localizing Add-on SDK-based Firefox features

Axel Hecht
In reply to this post by Myk Melez-3
On 15.11.11 19:01, David Ascher wrote:
> Right, my thought was to strictly use property files, and not entity
> references, for this scope of add-on SDK-based features.
>
> -da
>

The good news is that we can do most here anticipating l20n.

For html, that would mean starting to use the l10n-id as attribute. Use
a predefined set of attribute names that are safe to localize, and use
.properties that are like

foo: This would be a text node child.
foo_title: Title attribute
foo_label: A label attribute

with an html file

<img l10n-id="foo">

resulting in a DOM like
<img l10n-id="foo" title="Title attribute" label="A label attribute>This
would be a text node child.</img>

How does that sound?

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n