info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
document.mozL10n
408 views
Skip to first unread message
Fabien Cazenave
Mar 14, 2012, 4:03:45 PM3/14/12
to mozilla-d...@lists.mozilla.org, Fabien Cazenave
Dear all,
(writing again since my first message got "lost in moderation")
I’ve been working on an i18n/l10n library for Gaia.
Here’s the pull request: https://github.com/andreasgal/gaia/pull/759
Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
The HTML markup should be rather simple:
<html>
<head>
<script type="text/javascript" src="l10n.js"></script>
<link rel="resource" type="application/l10n" href="data.properties" />
</head>
<body>
<button data-l10n-id="test" title="click me!">This is a test</button>
</body>
</html>
• the <link/> element uses non-standard "rel" and "type" attributes
=> would that be an acceptable proposal for the HTML spec?
• translatable elements carry an "l10n-id" attribute
(the current library uses "data-l10n-id" to pass the validator)
The l10n resource data is in a *.properties file:
[en-US]
test=This is a test
test.title=click me!
[fr]
test=Ceci est un test
test.title=cliquez-moi !
The proposed JavaScript API is the following:
• methods:
.get(key, [arguments])
get the translated string corresponding to key
optional arguments can be passed for compound strings
.set(key, value)
update the translation of the string corresponding to key
• properties:
.language (read/write)
get/set the language of the current document (*)
.direction (read-only)
returns "ltr" or "rtl", depending on the current language
• event:
l10nLocaleLoaded
fired when the document has been translated
(e.g. on load, or when the language is changed dynamically)
Thoughts? Anything that should be renamed/removed/added?
Please let me know if I must be sharper. :-/
:kazé
(writing again since my first message got "lost in moderation")
I’ve been working on an i18n/l10n library for Gaia.
Here’s the pull request: https://github.com/andreasgal/gaia/pull/759
Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
The HTML markup should be rather simple:
<html>
<head>
<script type="text/javascript" src="l10n.js"></script>
<link rel="resource" type="application/l10n" href="data.properties" />
</head>
<body>
<button data-l10n-id="test" title="click me!">This is a test</button>
</body>
</html>
• the <link/> element uses non-standard "rel" and "type" attributes
=> would that be an acceptable proposal for the HTML spec?
• translatable elements carry an "l10n-id" attribute
(the current library uses "data-l10n-id" to pass the validator)
The l10n resource data is in a *.properties file:
[en-US]
test=This is a test
test.title=click me!
[fr]
test=Ceci est un test
test.title=cliquez-moi !
The proposed JavaScript API is the following:
• methods:
.get(key, [arguments])
get the translated string corresponding to key
optional arguments can be passed for compound strings
.set(key, value)
update the translation of the string corresponding to key
• properties:
.language (read/write)
get/set the language of the current document (*)
.direction (read-only)
returns "ltr" or "rtl", depending on the current language
• event:
l10nLocaleLoaded
fired when the document has been translated
(e.g. on load, or when the language is changed dynamically)
Thoughts? Anything that should be renamed/removed/added?
Please let me know if I must be sharper. :-/
:kazé
Rick Waldron
Mar 14, 2012, 4:08:14 PM3/14/12
to Fabien Cazenave, Fabien Cazenave, mozilla-d...@lists.mozilla.org
On Wed, Mar 14, 2012 at 4:03 PM, Fabien Cazenave <fab...@cazenave.cc> wrote:
> Dear all,
>
> (writing again since my first message got "lost in moderation")
>
> I’ve been working on an i18n/l10n library for Gaia.
> Here’s the pull request: https://github.com/andreasgal/**gaia/pull/759<https://github.com/andreasgal/gaia/pull/759>
> Dear all,
>
> (writing again since my first message got "lost in moderation")
>
> I’ve been working on an i18n/l10n library for Gaia.
> Here’s a bit of background: https://github.com/**fabi1cazenave/webL10n<https://github.com/fabi1cazenave/webL10n>
>
> The HTML markup should be rather simple:
>
> <html>
> <head>
> <script type="text/javascript" src="l10n.js"></script>
> <link rel="resource" type="application/l10n" href="data.properties" />
> </head>
> <body>
> <button data-l10n-id="test" title="click me!">This is a test</button>
> </body>
> </html>
>
> • the <link/> element uses non-standard "rel" and "type" attributes
> => would that be an acceptable proposal for the HTML spec?
> • translatable elements carry an "l10n-id" attribute
> (the current library uses "data-l10n-id" to pass the validator)
>
> The l10n resource data is in a *.properties file:
>
> [en-US]
> test=This is a test
> test.title=click me!
> [fr]
> test=Ceci est un test
> test.title=cliquez-moi !
>
>
Why not JSON? Or even YAML (with a parser)?
> The HTML markup should be rather simple:
>
> <html>
> <head>
> <script type="text/javascript" src="l10n.js"></script>
> <link rel="resource" type="application/l10n" href="data.properties" />
> </head>
> <body>
> <button data-l10n-id="test" title="click me!">This is a test</button>
> </body>
> </html>
>
> • the <link/> element uses non-standard "rel" and "type" attributes
> => would that be an acceptable proposal for the HTML spec?
> • translatable elements carry an "l10n-id" attribute
> (the current library uses "data-l10n-id" to pass the validator)
>
> The l10n resource data is in a *.properties file:
>
> [en-US]
> test=This is a test
> test.title=click me!
> [fr]
> test=Ceci est un test
> test.title=cliquez-moi !
>
>
> The proposed JavaScript API is the following:
>
> • methods:
> .get(key, [arguments])
> get the translated string corresponding to key
> optional arguments can be passed for compound strings
> .set(key, value)
> update the translation of the string corresponding to key
>
> • properties:
> .language (read/write)
> get/set the language of the current document (*)
> .direction (read-only)
> returns "ltr" or "rtl", depending on the current language
>
> • event:
> l10nLocaleLoaded
> fired when the document has been translated
> (e.g. on load, or when the language is changed dynamically)
>
> Thoughts? Anything that should be renamed/removed/added?
> Please let me know if I must be sharper. :-/
>
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
I'm sure they'd like 2-way input as well :)
Rick
>
> :kazé
> ______________________________**_________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-webapi<https://lists.mozilla.org/listinfo/dev-webapi>
>
JOSE MANUEL CANTERA FONSECA
Mar 14, 2012, 6:11:47 PM3/14/12
to Rick Waldron, Fabien Cazenave, mozilla-d...@lists.mozilla.org
I think we don't need JSON or YAML. the simple properties format proposed might be sufficient.
best
________________________________________
De: dev-webapi-bounces+jmcf=tid...@lists.mozilla.org [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] En nombre de Rick Waldron [waldro...@gmail.com]
Enviado el: miércoles, 14 de marzo de 2012 21:08
Para: Fabien Cazenave
CC: Fabien Cazenave; mozilla-d...@lists.mozilla.org
Asunto: Re: document.mozL10n
_______________________________________________
dev-webapi mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapi
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
best
________________________________________
De: dev-webapi-bounces+jmcf=tid...@lists.mozilla.org [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] En nombre de Rick Waldron [waldro...@gmail.com]
Enviado el: miércoles, 14 de marzo de 2012 21:08
Para: Fabien Cazenave
CC: Fabien Cazenave; mozilla-d...@lists.mozilla.org
Asunto: Re: document.mozL10n
dev-webapi mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapi
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Rick Waldron
Mar 14, 2012, 6:19:57 PM3/14/12
to JOSE MANUEL CANTERA FONSECA, Fabien Cazenave, mozilla-d...@lists.mozilla.org
How does the "properties" format get parsed?
Rick
Rick
JOSE MANUEL CANTERA FONSECA
Mar 14, 2012, 6:37:34 PM3/14/12
to Fabien Cazenave, mozilla-d...@lists.mozilla.org, Fabien Cazenave
The proposal sounds good. I would suggest to also support the following mechanism to load l10n strings
<script type="application/l10n">
This way l10n resources could be directly included on the page, thus improving network rountrips specially when minifying / optimizing the apps.
thanks, best
________________________________________
De: dev-webapi-bounces+jmcf=tid...@lists.mozilla.org [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] En nombre de Fabien Cazenave [fab...@cazenave.cc]
Enviado el: miércoles, 14 de marzo de 2012 21:03
Para: mozilla-d...@lists.mozilla.org
CC: Fabien Cazenave
Asunto: document.mozL10n
Dear all,
(writing again since my first message got "lost in moderation")
I’ve been working on an i18n/l10n library for Gaia.
Here’s the pull request: https://github.com/andreasgal/gaia/pull/759
Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
The HTML markup should be rather simple:
<html>
<head>
<script type="text/javascript" src="l10n.js"></script>
<link rel="resource" type="application/l10n" href="data.properties" />
</head>
<body>
<button data-l10n-id="test" title="click me!">This is a test</button>
</body>
</html>
• the <link/> element uses non-standard "rel" and "type" attributes
=> would that be an acceptable proposal for the HTML spec?
• translatable elements carry an "l10n-id" attribute
(the current library uses "data-l10n-id" to pass the validator)
The l10n resource data is in a *.properties file:
[en-US]
test=This is a test
test.title=click me!
[fr]
test=Ceci est un test
test.title=cliquez-moi !
<script type="application/l10n">
[en-US]
test=This is a test
test.title=click me!
[fr]
test=Ceci est un test
test.title=cliquez-moi !
</script>
test=This is a test
test.title=click me!
[fr]
test=Ceci est un test
test.title=cliquez-moi !
This way l10n resources could be directly included on the page, thus improving network rountrips specially when minifying / optimizing the apps.
thanks, best
________________________________________
De: dev-webapi-bounces+jmcf=tid...@lists.mozilla.org [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] En nombre de Fabien Cazenave [fab...@cazenave.cc]
Enviado el: miércoles, 14 de marzo de 2012 21:03
Para: mozilla-d...@lists.mozilla.org
CC: Fabien Cazenave
Asunto: document.mozL10n
Dear all,
(writing again since my first message got "lost in moderation")
I’ve been working on an i18n/l10n library for Gaia.
Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
The HTML markup should be rather simple:
<html>
<head>
<script type="text/javascript" src="l10n.js"></script>
<link rel="resource" type="application/l10n" href="data.properties" />
</head>
<body>
<button data-l10n-id="test" title="click me!">This is a test</button>
</body>
</html>
• the <link/> element uses non-standard "rel" and "type" attributes
=> would that be an acceptable proposal for the HTML spec?
• translatable elements carry an "l10n-id" attribute
(the current library uses "data-l10n-id" to pass the validator)
The l10n resource data is in a *.properties file:
[en-US]
test=This is a test
test.title=click me!
[fr]
test=Ceci est un test
test.title=cliquez-moi !
The proposed JavaScript API is the following:
• methods:
.get(key, [arguments])
get the translated string corresponding to key
optional arguments can be passed for compound strings
.set(key, value)
update the translation of the string corresponding to key
• properties:
.language (read/write)
get/set the language of the current document (*)
.direction (read-only)
returns "ltr" or "rtl", depending on the current language
• event:
l10nLocaleLoaded
fired when the document has been translated
(e.g. on load, or when the language is changed dynamically)
Thoughts? Anything that should be renamed/removed/added?
Please let me know if I must be sharper. :-/
:kazé
• methods:
.get(key, [arguments])
get the translated string corresponding to key
optional arguments can be passed for compound strings
.set(key, value)
update the translation of the string corresponding to key
• properties:
.language (read/write)
get/set the language of the current document (*)
.direction (read-only)
returns "ltr" or "rtl", depending on the current language
• event:
l10nLocaleLoaded
fired when the document has been translated
(e.g. on load, or when the language is changed dynamically)
Thoughts? Anything that should be renamed/removed/added?
Please let me know if I must be sharper. :-/
JOSE MANUEL CANTERA FONSECA
Mar 14, 2012, 6:54:51 PM3/14/12
to Rick Waldron, Fabien Cazenave, mozilla-d...@lists.mozilla.org
that would be trivial to decorate it with '[' and '{' and to use JSON.parse to parse it ;)
My point is that the advantage of the simple properties format is that it can be used easily by non-programmers (usually translators are in charge of producing these l10n files) without any special syntax burden
thanks, best
________________________________________
De: Rick Waldron [waldro...@gmail.com]
Enviado el: miércoles, 14 de marzo de 2012 23:19
Para: JOSE MANUEL CANTERA FONSECA
> ________________________________________
>> Here’s a bit of background: https://github.com/**fabi1cazenave/webL10n<https://github.com/fabi1cazenave/webL10n>
>> dev-w...@lists.mozilla.org
>> https://lists.mozilla.org/**listinfo/dev-webapi<https://lists.mozilla.org/listinfo/dev-webapi>
My point is that the advantage of the simple properties format is that it can be used easily by non-programmers (usually translators are in charge of producing these l10n files) without any special syntax burden
thanks, best
________________________________________
De: Rick Waldron [waldro...@gmail.com]
Enviado el: miércoles, 14 de marzo de 2012 23:19
Para: JOSE MANUEL CANTERA FONSECA
How does the "properties" format get parsed?
Rick
On Mar 14, 2012, at 6:11 PM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
> I think we don't need JSON or YAML. the simple properties format proposed might be sufficient.
>
> best
Rick
On Mar 14, 2012, at 6:11 PM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
> I think we don't need JSON or YAML. the simple properties format proposed might be sufficient.
>
> ________________________________________
> De: dev-webapi-bounces+jmcf=tid...@lists.mozilla.org [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] En nombre de Rick Waldron [waldro...@gmail.com]
> Enviado el: miércoles, 14 de marzo de 2012 21:08
> Para: Fabien Cazenave
> CC: Fabien Cazenave; mozilla-d...@lists.mozilla.org
> Asunto: Re: document.mozL10n
>
> On Wed, Mar 14, 2012 at 4:03 PM, Fabien Cazenave <fab...@cazenave.cc> wrote:
>
> Enviado el: miércoles, 14 de marzo de 2012 21:08
> Para: Fabien Cazenave
> CC: Fabien Cazenave; mozilla-d...@lists.mozilla.org
> Asunto: Re: document.mozL10n
>
> On Wed, Mar 14, 2012 at 4:03 PM, Fabien Cazenave <fab...@cazenave.cc> wrote:
>
>> Dear all,
>>
>> (writing again since my first message got "lost in moderation")
>>
>> I’ve been working on an i18n/l10n library for Gaia.
>> Here’s the pull request: https://github.com/andreasgal/**gaia/pull/759<https://github.com/andreasgal/gaia/pull/759>
>>
>> (writing again since my first message got "lost in moderation")
>>
>> I’ve been working on an i18n/l10n library for Gaia.
>> Here’s a bit of background: https://github.com/**fabi1cazenave/webL10n<https://github.com/fabi1cazenave/webL10n>
>>
>> The HTML markup should be rather simple:
>>
>> <html>
>> <head>
>> <script type="text/javascript" src="l10n.js"></script>
>> <link rel="resource" type="application/l10n" href="data.properties" />
>> </head>
>> <body>
>> <button data-l10n-id="test" title="click me!">This is a test</button>
>> </body>
>> </html>
>>
>> • the <link/> element uses non-standard "rel" and "type" attributes
>> => would that be an acceptable proposal for the HTML spec?
>> • translatable elements carry an "l10n-id" attribute
>> (the current library uses "data-l10n-id" to pass the validator)
>>
>> The l10n resource data is in a *.properties file:
>>
>> [en-US]
>> test=This is a test
>> test.title=click me!
>> [fr]
>> test=Ceci est un test
>> test.title=cliquez-moi !
>>
>>
>> The HTML markup should be rather simple:
>>
>> <html>
>> <head>
>> <script type="text/javascript" src="l10n.js"></script>
>> <link rel="resource" type="application/l10n" href="data.properties" />
>> </head>
>> <body>
>> <button data-l10n-id="test" title="click me!">This is a test</button>
>> </body>
>> </html>
>>
>> • the <link/> element uses non-standard "rel" and "type" attributes
>> => would that be an acceptable proposal for the HTML spec?
>> • translatable elements carry an "l10n-id" attribute
>> (the current library uses "data-l10n-id" to pass the validator)
>>
>> The l10n resource data is in a *.properties file:
>>
>> [en-US]
>> test=This is a test
>> test.title=click me!
>> [fr]
>> test=Ceci est un test
>> test.title=cliquez-moi !
>>
>>
> Why not JSON? Or even YAML (with a parser)?
>
>
>
>
>
>
>
>
>
>
>
>
>> The proposed JavaScript API is the following:
>>
>> • methods:
>> .get(key, [arguments])
>> get the translated string corresponding to key
>> optional arguments can be passed for compound strings
>> .set(key, value)
>> update the translation of the string corresponding to key
>>
>> • properties:
>> .language (read/write)
>> get/set the language of the current document (*)
>> .direction (read-only)
>> returns "ltr" or "rtl", depending on the current language
>>
>> • event:
>> l10nLocaleLoaded
>> fired when the document has been translated
>> (e.g. on load, or when the language is changed dynamically)
>>
>> Thoughts? Anything that should be renamed/removed/added?
>> Please let me know if I must be sharper. :-/
>>
>
>
>>
>> • methods:
>> .get(key, [arguments])
>> get the translated string corresponding to key
>> optional arguments can be passed for compound strings
>> .set(key, value)
>> update the translation of the string corresponding to key
>>
>> • properties:
>> .language (read/write)
>> get/set the language of the current document (*)
>> .direction (read-only)
>> returns "ltr" or "rtl", depending on the current language
>>
>> • event:
>> l10nLocaleLoaded
>> fired when the document has been translated
>> (e.g. on load, or when the language is changed dynamically)
>>
>> Thoughts? Anything that should be renamed/removed/added?
>> Please let me know if I must be sharper. :-/
>>
>
>
> You may also want to rope in the Globalization spec guys here:
> http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
>
> I'm sure they'd like 2-way input as well :)
>
> Rick
>
>
>
>
>>
>> :kazé
>> ______________________________**_________________
>> dev-webapi mailing list
> http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
>
> I'm sure they'd like 2-way input as well :)
>
> Rick
>
>
>
>
>>
>> :kazé
>> ______________________________**_________________
>> dev-w...@lists.mozilla.org
>> https://lists.mozilla.org/**listinfo/dev-webapi<https://lists.mozilla.org/listinfo/dev-webapi>
Reuben Morais
Mar 14, 2012, 8:05:48 PM3/14/12
to dev-w...@lists.mozilla.org
Why aren't we using L20n for B2G? I think this is a great chance
(fresh start) to push it,
and according to the roadmap page[1] for 1.0 it already covers what
mozL10n is doing.
[1] https://wiki.mozilla.org/L20n/Roadmap/1.0#Ready
-- reuben
(fresh start) to push it,
and according to the roadmap page[1] for 1.0 it already covers what
mozL10n is doing.
[1] https://wiki.mozilla.org/L20n/Roadmap/1.0#Ready
-- reuben
Chris Jones
Mar 14, 2012, 9:25:31 PM3/14/12
to Fabien Cazenave, Fabien Cazenave, mozilla-d...@lists.mozilla.org
Hi kaze,
There was discussion about l10n/i18n in HTML on I believe dev-b2g ... did you take a look over the "l20n" proposal from Moz? I think it would be useful to start from things you dislike in that proposal, and would like to see changed, rather than with a new proposal from scratch.
Cheers,
Chris
----- Original Message -----
> From: "Fabien Cazenave" <fab...@cazenave.cc>
> To: mozilla-d...@lists.mozilla.org
> Cc: "Fabien Cazenave" <ka...@mozilla.com>
> Sent: Wednesday, March 14, 2012 1:03:45 PM
> Subject: document.mozL10n
>
> Dear all,
>
> (writing again since my first message got "lost in moderation")
>
> I’ve been working on an i18n/l10n library for Gaia.
> Here’s the pull request: https://github.com/andreasgal/gaia/pull/759
> Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
There was discussion about l10n/i18n in HTML on I believe dev-b2g ... did you take a look over the "l20n" proposal from Moz? I think it would be useful to start from things you dislike in that proposal, and would like to see changed, rather than with a new proposal from scratch.
Cheers,
Chris
----- Original Message -----
> From: "Fabien Cazenave" <fab...@cazenave.cc>
> To: mozilla-d...@lists.mozilla.org
> Cc: "Fabien Cazenave" <ka...@mozilla.com>
> Sent: Wednesday, March 14, 2012 1:03:45 PM
> Subject: document.mozL10n
>
> Dear all,
>
> (writing again since my first message got "lost in moderation")
>
> I’ve been working on an i18n/l10n library for Gaia.
> Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
>
> The HTML markup should be rather simple:
>
> <html>
> <head>
> <script type="text/javascript" src="l10n.js"></script>
> <link rel="resource" type="application/l10n"
> href="data.properties" />
> </head>
> <body>
> <button data-l10n-id="test" title="click me!">This is a
> test</button>
> </body>
> </html>
>
> • the <link/> element uses non-standard "rel" and "type" attributes
> => would that be an acceptable proposal for the HTML spec?
> • translatable elements carry an "l10n-id" attribute
> (the current library uses "data-l10n-id" to pass the validator)
>
> The l10n resource data is in a *.properties file:
>
> [en-US]
> test=This is a test
> test.title=click me!
> [fr]
> test=Ceci est un test
> test.title=cliquez-moi !
>
> The HTML markup should be rather simple:
>
> <html>
> <head>
> <script type="text/javascript" src="l10n.js"></script>
> <link rel="resource" type="application/l10n"
> href="data.properties" />
> </head>
> <body>
> <button data-l10n-id="test" title="click me!">This is a
> test</button>
> </body>
> </html>
>
> • the <link/> element uses non-standard "rel" and "type" attributes
> => would that be an acceptable proposal for the HTML spec?
> • translatable elements carry an "l10n-id" attribute
> (the current library uses "data-l10n-id" to pass the validator)
>
> The l10n resource data is in a *.properties file:
>
> [en-US]
> test=This is a test
> test.title=click me!
> [fr]
> test=Ceci est un test
> test.title=cliquez-moi !
>
> The proposed JavaScript API is the following:
>
> • methods:
> .get(key, [arguments])
> get the translated string corresponding to key
> optional arguments can be passed for compound strings
> .set(key, value)
> update the translation of the string corresponding to key
>
> • properties:
> .language (read/write)
> get/set the language of the current document (*)
> .direction (read-only)
> returns "ltr" or "rtl", depending on the current language
>
> • event:
> l10nLocaleLoaded
> fired when the document has been translated
> (e.g. on load, or when the language is changed dynamically)
>
> Thoughts? Anything that should be renamed/removed/added?
> Please let me know if I must be sharper. :-/
>
> :kazé
>
> • methods:
> .get(key, [arguments])
> get the translated string corresponding to key
> optional arguments can be passed for compound strings
> .set(key, value)
> update the translation of the string corresponding to key
>
> • properties:
> .language (read/write)
> get/set the language of the current document (*)
> .direction (read-only)
> returns "ltr" or "rtl", depending on the current language
>
> • event:
> l10nLocaleLoaded
> fired when the document has been translated
> (e.g. on load, or when the language is changed dynamically)
>
> Thoughts? Anything that should be renamed/removed/added?
> Please let me know if I must be sharper. :-/
>
JOSE MANUEL CANTERA FONSECA
Mar 15, 2012, 4:39:40 AM3/15/12
to Chris Jones, Fabien Cazenave, mozilla-d...@lists.mozilla.org, Fabien Cazenave
Hi Chris,
Could you point to specific technical materials on l20n?. It seems that
l20n proposal is 'too ambitious' for what we really need for typical apps
on mobile phones. A simple approach like the one proposed by Caze can just
work.
Thanks, best
El 15/03/12 02:25, "Chris Jones" <cjo...@mozilla.com> escribió:
Could you point to specific technical materials on l20n?. It seems that
l20n proposal is 'too ambitious' for what we really need for typical apps
on mobile phones. A simple approach like the one proposed by Caze can just
work.
Thanks, best
El 15/03/12 02:25, "Chris Jones" <cjo...@mozilla.com> escribió:
Fabien Cazenave
Mar 15, 2012, 5:39:43 AM3/15/12
to Chris Jones
Hi Chris,
Le 15/03/2012 02:25, Chris Jones a écrit :
> There was discussion about l10n/i18n in HTML on I believe dev-b2g ... did you take a look over the "l20n" proposal from Moz?
yes, we’ve had a very close look at the “l20n” proposal and their “LOL”
format. I’ve also contributed some code to the l20n project, including
a parser: http://kazhack.org/webL10n/LOL/
At the moment, neither the l20n tools (e.g. interpreters) nor the “LOL”
format are ready. There’s no consensus on the format nor on the API
either. And we have to come up with something on Gaia now, even if we
have to evolve later.
>I think it would be useful to start from things you dislike in that
proposal, and would like to see changed, rather than with a new proposal
from scratch.
We’re in the middle of this process, which started months ago.
We had meeting with Pike and Gandalf to expose what we dislike, what we
needed which wasn’t supported “by design”, and a proposal to make it
work for us. This has been (strongly) rejected, that’s why we currently
rely on the biggest common denominator:
• the l20n HTML markup proposal (data-l10n-id);
• the l20n {{arguments}} syntax in strings;
• the *.properties format, already in use by most Mozilla projects.
We’ve asked the l20n team to start an open discussion on their work on
m.d.l10n. The l20n team has a very interesting approach to handle
complex grammatical cases (“expressions”), but there are limitations and
oddities in the current format that we’d like to solve before
implementing it. Believe me, the discussion will be very long. :-)
At this stage, I think we should focus on the HTML markup proposal and
the JS API. The resource format is rather secondary here, but it’d be a
blocker if we had to use the current “LOL” proposal.
In particular, I’d like to discuss the “resource” thing:
rather than <script/>). I also think it could be used for non-l10n
purposes, e.g. to include a data set in a web page. But in the short
term, I’d like to know whether this makes sense, and if these rel/type
values could be proposed.
I also would like to start the discussion on the l10n API here. This
seems to be the right place to debate over the API. :-)
Cheers,
:kazé
Le 15/03/2012 02:25, Chris Jones a écrit :
> There was discussion about l10n/i18n in HTML on I believe dev-b2g ... did you take a look over the "l20n" proposal from Moz?
format. I’ve also contributed some code to the l20n project, including
a parser: http://kazhack.org/webL10n/LOL/
At the moment, neither the l20n tools (e.g. interpreters) nor the “LOL”
format are ready. There’s no consensus on the format nor on the API
either. And we have to come up with something on Gaia now, even if we
have to evolve later.
>I think it would be useful to start from things you dislike in that
proposal, and would like to see changed, rather than with a new proposal
from scratch.
We had meeting with Pike and Gandalf to expose what we dislike, what we
needed which wasn’t supported “by design”, and a proposal to make it
work for us. This has been (strongly) rejected, that’s why we currently
rely on the biggest common denominator:
• the l20n HTML markup proposal (data-l10n-id);
• the l20n {{arguments}} syntax in strings;
• the *.properties format, already in use by most Mozilla projects.
We’ve asked the l20n team to start an open discussion on their work on
m.d.l10n. The l20n team has a very interesting approach to handle
complex grammatical cases (“expressions”), but there are limitations and
oddities in the current format that we’d like to solve before
implementing it. Believe me, the discussion will be very long. :-)
At this stage, I think we should focus on the HTML markup proposal and
the JS API. The resource format is rather secondary here, but it’d be a
blocker if we had to use the current “LOL” proposal.
In particular, I’d like to discuss the “resource” thing:
<link rel="resource" type="application/l10n" href="data.properties" />
I agree I’d also like to include it in an HTML page (e.g. <resource/>
rather than <script/>). I also think it could be used for non-l10n
purposes, e.g. to include a data set in a web page. But in the short
term, I’d like to know whether this makes sense, and if these rel/type
values could be proposed.
I also would like to start the discussion on the l10n API here. This
seems to be the right place to debate over the API. :-)
Cheers,
:kazé
Vivien
Mar 15, 2012, 8:28:29 AM3/15/12
to Chris Jones, Axel Hecht, Fabien Cazenave, mozilla-d...@lists.mozilla.org, Fabien Cazenave
On 15/03/2012 02:25, Chris Jones wrote:
> Hi kaze,
>
> There was discussion about l10n/i18n in HTML on I believe dev-b2g ... did you take a look over the "l20n" proposal from Moz? I think it would be useful to start from things you dislike in that proposal, and would like to see changed, rather than with a new proposal from scratch.
Hey Chris,
The proposal is not from 'scratch'. It uses the L20n approach for html
attributes, like l10n-id for example.
The mozL10n object is also taken from their proposal. The API and the
file format are slightly different but until there is a consensus on the
file format, the l10n team is fine with .properties.
Axel, am I incorrect here?
> Cheers,
> Chris
>
> ----- Original Message -----
>> From: "Fabien Cazenave"<fab...@cazenave.cc>
>> To: mozilla-d...@lists.mozilla.org
>> Cc: "Fabien Cazenave"<ka...@mozilla.com>
>> Sent: Wednesday, March 14, 2012 1:03:45 PM
>> Subject: document.mozL10n
>>
>> Dear all,
>>
>> (writing again since my first message got "lost in moderation")
>>
>> I’ve been working on an i18n/l10n library for Gaia.
>> Here’s the pull request: https://github.com/andreasgal/gaia/pull/759
>> Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
>>
>> The HTML markup should be rather simple:
>>
>> <html>
>> <head>
>> <script type="text/javascript" src="l10n.js"></script>
> Hi kaze,
>
> There was discussion about l10n/i18n in HTML on I believe dev-b2g ... did you take a look over the "l20n" proposal from Moz? I think it would be useful to start from things you dislike in that proposal, and would like to see changed, rather than with a new proposal from scratch.
Hey Chris,
The proposal is not from 'scratch'. It uses the L20n approach for html
attributes, like l10n-id for example.
The mozL10n object is also taken from their proposal. The API and the
file format are slightly different but until there is a consensus on the
file format, the l10n team is fine with .properties.
Axel, am I incorrect here?
> Cheers,
> Chris
>
> ----- Original Message -----
>> From: "Fabien Cazenave"<fab...@cazenave.cc>
>> To: mozilla-d...@lists.mozilla.org
>> Cc: "Fabien Cazenave"<ka...@mozilla.com>
>> Sent: Wednesday, March 14, 2012 1:03:45 PM
>> Subject: document.mozL10n
>>
>> Dear all,
>>
>> (writing again since my first message got "lost in moderation")
>>
>> I’ve been working on an i18n/l10n library for Gaia.
>> Here’s the pull request: https://github.com/andreasgal/gaia/pull/759
>> Here’s a bit of background: https://github.com/fabi1cazenave/webL10n
>>
>> The HTML markup should be rather simple:
>>
>> <html>
>> <head>
>> <script type="text/javascript" src="l10n.js"></script>
>> <link rel="resource" type="application/l10n"
>> href="data.properties" />
>> href="data.properties" />
Reuben Morais
Mar 14, 2012, 7:38:32 PM3/14/12
to mozilla-d...@lists.mozilla.org
Why aren't we using/working on L20n for B2G? I think this is a great
chance (fresh start) to push it forward, and according to the roadmap
chance (fresh start) to push it forward, and according to the roadmap
page[1] for 1.0 it already covers what mozL10n is doing.
https://wiki.mozilla.org/L20n
Axel Hecht
Mar 15, 2012, 8:47:09 AM3/15/12
to Vivien, Zbigniew Braniecki, Fabien Cazenave, Stanislaw Malolepszy, Fabien Cazenave, Chris Jones, mozilla-d...@lists.mozilla.org
I'm not the right guy to ask, gandalf or stas would be.
As the initial inventor of l20n, I'd add that I don't think that we're
talking about different fileformats per se, but more about different
designs trying to solve similar problems, though not 100% the same problems.
Axel
PS: The cited file example below is not a .properties file
As the initial inventor of l20n, I'd add that I don't think that we're
talking about different fileformats per se, but more about different
designs trying to solve similar problems, though not 100% the same problems.
Axel
PS: The cited file example below is not a .properties file
Chris Jones
Mar 15, 2012, 9:58:06 PM3/15/12
to JOSE MANUEL CANTERA FONSECA, Fabien Cazenave, mozilla-d...@lists.mozilla.org, Fabien Cazenave
----- Original Message -----
> From: "JOSE MANUEL CANTERA FONSECA" <jm...@tid.es>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Fabien Cazenave" <ka...@mozilla.com>, mozilla-d...@lists.mozilla.org, "Fabien Cazenave"
> <fab...@cazenave.cc>
> Sent: Thursday, March 15, 2012 1:39:40 AM
> Subject: Re: document.mozL10n
>
> Hi Chris,
>
> Could you point to specific technical materials on l20n?.
This is the thread I was referring to
> From: "JOSE MANUEL CANTERA FONSECA" <jm...@tid.es>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Fabien Cazenave" <ka...@mozilla.com>, mozilla-d...@lists.mozilla.org, "Fabien Cazenave"
> <fab...@cazenave.cc>
> Sent: Thursday, March 15, 2012 1:39:40 AM
> Subject: Re: document.mozL10n
>
> Hi Chris,
>
> Could you point to specific technical materials on l20n?.
http://groups.google.com/group/mozilla.dev.b2g/browse_thread/thread/841a0aef5f0a719f/f0d4d4ffa3feb0aa
> It seems
> that
> l20n proposal is 'too ambitious' for what we really need for typical
> apps
> on mobile phones. A simple approach like the one proposed by Caze can
> just
> work.
>
Cheers,
Chris
> >Hi kaze,
> >
> >There was discussion about l10n/i18n in HTML on I believe dev-b2g
> >... did
> >you take a look over the "l20n" proposal from Moz? I think it would
> >be
> >useful to start from things you dislike in that proposal, and would
> >like
> >to see changed, rather than with a new proposal from scratch.
> >
> >
> >There was discussion about l10n/i18n in HTML on I believe dev-b2g
> >... did
> >you take a look over the "l20n" proposal from Moz? I think it would
> >be
> >useful to start from things you dislike in that proposal, and would
> >like
> >to see changed, rather than with a new proposal from scratch.
> >
Mounir Lamouri
Mar 16, 2012, 10:53:47 AM3/16/12
to dev-w...@lists.mozilla.org, Jonas Sicking
On 03/14/2012 09:03 PM, Fabien Cazenave wrote:
> • methods:
not have one.
> • properties:
about navigator.language. Jonas, do you think we make navigator.language
returning the requested content language? If so, can we make it writable
(if permissions are given). IOW, given that it's DOM0 (aka not part of
any specs), do you think it would break the web to change the behavior?
I would tend to say yes.
Also, regarding .direction, I would prefer: l10n.language.direction
instead of of l10n.direction (in that case, we could have
l10n.language.name).
> • event:
not be clear if the propoerty file got loaded or if the
translation/localization is done. I would prefer a simple "localized" or
"translated" event.
Cheers,
--
Mounir
> • methods:
> .get(key, [arguments])
> get the translated string corresponding to key
> optional arguments can be passed for compound strings
> .set(key, value)
> update the translation of the string corresponding to key
What would be the use case for a set() method? I would really prefer to
> get the translated string corresponding to key
> optional arguments can be passed for compound strings
> .set(key, value)
> update the translation of the string corresponding to key
not have one.
> • properties:
> .language (read/write)
> get/set the language of the current document (*)
> .direction (read-only)
> returns "ltr" or "rtl", depending on the current language
So, we had a discussion during the HTML5 Games work week with Jonas
> get/set the language of the current document (*)
> .direction (read-only)
> returns "ltr" or "rtl", depending on the current language
about navigator.language. Jonas, do you think we make navigator.language
returning the requested content language? If so, can we make it writable
(if permissions are given). IOW, given that it's DOM0 (aka not part of
any specs), do you think it would break the web to change the behavior?
I would tend to say yes.
Also, regarding .direction, I would prefer: l10n.language.direction
instead of of l10n.direction (in that case, we could have
l10n.language.name).
> • event:
> l10nLocaleLoaded
> fired when the document has been translated
> (e.g. on load, or when the language is changed dynamically)
It's probably bikeshedding but the event name seems confusing. It might
> fired when the document has been translated
> (e.g. on load, or when the language is changed dynamically)
not be clear if the propoerty file got loaded or if the
translation/localization is done. I would prefer a simple "localized" or
"translated" event.
Cheers,
--
Mounir
Fabien Cazenave
Mar 16, 2012, 4:28:58 PM3/16/12
to Mounir Lamouri
Le 16/03/2012 15:53, Mounir Lamouri a écrit :
> On 03/14/2012 09:03 PM, Fabien Cazenave wrote:
>> • methods:
>> .get(key, [arguments])
>> get the translated string corresponding to key
>> optional arguments can be passed for compound strings
>> .set(key, value)
>> update the translation of the string corresponding to key
>
> What would be the use case for a set() method? I would really prefer to
> not have one.
The only use case I have in mind would be an l10n resource editor.
> On 03/14/2012 09:03 PM, Fabien Cazenave wrote:
>> • methods:
>> .get(key, [arguments])
>> get the translated string corresponding to key
>> optional arguments can be passed for compound strings
>> .set(key, value)
>> update the translation of the string corresponding to key
>
> What would be the use case for a set() method? I would really prefer to
> not have one.
I guess it’s the same as for the CSS stylesheet API, where setters are
rarely used (except in CSS editors).
I agree we could survive without .set() here. :-)
If we have no .set() method, should we still use ".get()" or should it
be another (more explicit) name?
>> • properties:
>> .language (read/write)
>> get/set the language of the current document (*)
>> .direction (read-only)
>> returns "ltr" or "rtl", depending on the current language
>
> So, we had a discussion during the HTML5 Games work week with Jonas
> about navigator.language. Jonas, do you think we make navigator.language
> returning the requested content language? If so, can we make it writable
> (if permissions are given). IOW, given that it's DOM0 (aka not part of
> any specs), do you think it would break the web to change the behavior?
> I would tend to say yes.
very different things. I’d prefer to leave navigator.language as is.
However, I’d love to expose a *list* of content languages that are
negotiated by the browser (we have a pref for that).
> Also, regarding .direction, I would prefer: l10n.language.direction
> instead of of l10n.direction (in that case, we could have
> l10n.language.name).
+ l10n.language.name to match the ISO 639-1 code and the name of the
locale, respectively (e.g. "fr" and "français" for French).
>> • event:
>> l10nLocaleLoaded
>> fired when the document has been translated
>> (e.g. on load, or when the language is changed dynamically)
>
> It's probably bikeshedding but the event name seems confusing. It might
> not be clear if the propoerty file got loaded or if the
> translation/localization is done. I would prefer a simple "localized" or
> "translated" event.
Would "localized" please everyone?
:kazé
Mounir Lamouri
Mar 19, 2012, 12:14:17 PM3/19/12
to dev-w...@lists.mozilla.org
On 03/16/2012 09:28 PM, Fabien Cazenave wrote:
> Le 16/03/2012 15:53, Mounir Lamouri a écrit :
> Le 16/03/2012 15:53, Mounir Lamouri a écrit :
>> On 03/14/2012 09:03 PM, Fabien Cazenave wrote:
>>> • methods:
>>> .get(key, [arguments])
>>> get the translated string corresponding to key
>>> optional arguments can be passed for compound strings
>>> .set(key, value)
>>> update the translation of the string corresponding to key
>>
>> What would be the use case for a set() method? I would really prefer to
>> not have one.
>
>>> • methods:
>>> .get(key, [arguments])
>>> get the translated string corresponding to key
>>> optional arguments can be passed for compound strings
>>> .set(key, value)
>>> update the translation of the string corresponding to key
>>
>> What would be the use case for a set() method? I would really prefer to
>> not have one.
>
> The only use case I have in mind would be an l10n resource editor.
> I guess it’s the same as for the CSS stylesheet API, where setters are
> rarely used (except in CSS editors).
>
> I agree we could survive without .set() here. :-)
>
> If we have no .set() method, should we still use ".get()" or should it
> be another (more explicit) name?
I would tend to say we could live without .set() for the moment and adds
> I guess it’s the same as for the CSS stylesheet API, where setters are
> rarely used (except in CSS editors).
>
> I agree we could survive without .set() here. :-)
>
> If we have no .set() method, should we still use ".get()" or should it
> be another (more explicit) name?
it later if needed. But we can keep get() as is.
>>> • properties:
>>> .language (read/write)
>>> get/set the language of the current document (*)
>>> .direction (read-only)
>>> returns "ltr" or "rtl", depending on the current language
>>
>> So, we had a discussion during the HTML5 Games work week with Jonas
>> about navigator.language. Jonas, do you think we make navigator.language
>> returning the requested content language? If so, can we make it writable
>> (if permissions are given). IOW, given that it's DOM0 (aka not part of
>> any specs), do you think it would break the web to change the behavior?
>> I would tend to say yes.
>
> I’d think the document language and the browser preferred language are
> very different things. I’d prefer to leave navigator.language as is.
So, that's exactly why I want Jonas' opinion. I wonder if there is any
> very different things. I’d prefer to leave navigator.language as is.
reason to expose both information: UI language and preferred content
language. My feeling is that content doesn't need to know the browser
UI's language.
> However, I’d love to expose a *list* of content languages that are
> negotiated by the browser (we have a pref for that).
fingerprinting... and I don't see any use case. (though, do we send that
list in the HTTP request?)
>> Also, regarding .direction, I would prefer: l10n.language.direction
>> instead of of l10n.direction (in that case, we could have
>> l10n.language.name).
> Why not. If we’re getting there, maybe we could have l10n.language.code
> + l10n.language.name to match the ISO 639-1 code and the name of the
> locale, respectively (e.g. "fr" and "français" for French).
language.name but you could use language.code for the moment so if it
happens that language.name is needed, we will just have to add it.
--
Mounir
Fabien Cazenave
Mar 19, 2012, 1:25:00 PM3/19/12
to Mounir Lamouri
So here’s the resulting API at the moment:
document.mozL10n.get(key, [params])
document.mozL10n.language.name (read/write property)
document.mozL10n.language.direction (read-only property)
+ 'localized' event
Does it look right?
Le 19/03/2012 17:14, Mounir Lamouri a écrit :
> On 03/16/2012 09:28 PM, Fabien Cazenave wrote:
>> Le 16/03/2012 15:53, Mounir Lamouri a écrit :
>>> On 03/14/2012 09:03 PM, Fabien Cazenave wrote:
>> I’d think the document language and the browser preferred language are
>> very different things. I’d prefer to leave navigator.language as is.
>
> So, that's exactly why I want Jonas' opinion. I wonder if there is any
> reason to expose both information: UI language and preferred content
> language. My feeling is that content doesn't need to know the browser
> UI's language.
>
>> However, I’d love to expose a *list* of content languages that are
>> negotiated by the browser (we have a pref for that).
>
> Please, don't. Some websites would love to use that information for
> fingerprinting... and I don't see any use case. (though, do we send that
> list in the HTTP request?)
>
OK, I understand exposing a list can be a bad idea, but we do need some
way to default to a relevant language, e.g. a Catalan user might prefer
a Spanish locale over an English one if no Catalan locale is available
for the document.
We’d have to do some kind of content negotiation, like we do with HTTP
servers.
:kazé
document.mozL10n.get(key, [params])
document.mozL10n.language.name (read/write property)
document.mozL10n.language.direction (read-only property)
+ 'localized' event
Does it look right?
Le 19/03/2012 17:14, Mounir Lamouri a écrit :
> On 03/16/2012 09:28 PM, Fabien Cazenave wrote:
>> Le 16/03/2012 15:53, Mounir Lamouri a écrit :
>>> On 03/14/2012 09:03 PM, Fabien Cazenave wrote:
>> I’d think the document language and the browser preferred language are
>> very different things. I’d prefer to leave navigator.language as is.
>
> So, that's exactly why I want Jonas' opinion. I wonder if there is any
> reason to expose both information: UI language and preferred content
> language. My feeling is that content doesn't need to know the browser
> UI's language.
>
>> However, I’d love to expose a *list* of content languages that are
>> negotiated by the browser (we have a pref for that).
>
> Please, don't. Some websites would love to use that information for
> fingerprinting... and I don't see any use case. (though, do we send that
> list in the HTTP request?)
>
way to default to a relevant language, e.g. a Catalan user might prefer
a Spanish locale over an English one if no Catalan locale is available
for the document.
We’d have to do some kind of content negotiation, like we do with HTTP
servers.
:kazé
Mounir Lamouri
Mar 20, 2012, 11:42:19 AM3/20/12
to dev-w...@lists.mozilla.org
On 03/19/2012 06:25 PM, Fabien Cazenave wrote:
> So here’s the resulting API at the moment:
>
> document.mozL10n.get(key, [params])
> document.mozL10n.language.name (read/write property)
Why not .code instead of .name?
> So here’s the resulting API at the moment:
>
> document.mozL10n.get(key, [params])
> document.mozL10n.language.name (read/write property)
>> On 03/16/2012 09:28 PM, Fabien Cazenave wrote:
> OK, I understand exposing a list can be a bad idea, but we do need some
> way to default to a relevant language, e.g. a Catalan user might prefer
> a Spanish locale over an English one if no Catalan locale is available
> for the document.
>
> We’d have to do some kind of content negotiation, like we do with HTTP
> servers.
Yes, I was assuming the UA would be able to select the language that
> way to default to a relevant language, e.g. a Catalan user might prefer
> a Spanish locale over an English one if no Catalan locale is available
> for the document.
>
> We’d have to do some kind of content negotiation, like we do with HTTP
> servers.
fits user expectations.
--
Mounir
Fabien Cazenave
Mar 20, 2012, 3:35:08 PM3/20/12
to Mounir Lamouri, dev-w...@lists.mozilla.org
Le 20/03/2012 16:42, Mounir Lamouri a écrit :
> On 03/19/2012 06:25 PM, Fabien Cazenave wrote:
>> So here’s the resulting API at the moment:
>>
>> document.mozL10n.get(key, [params])
>> document.mozL10n.language.name (read/write property)
>
> Why not .code instead of .name?
>
.code then. So be it! :-)
> On 03/19/2012 06:25 PM, Fabien Cazenave wrote:
>> So here’s the resulting API at the moment:
>>
>> document.mozL10n.get(key, [params])
>> document.mozL10n.language.name (read/write property)
>
> Why not .code instead of .name?
>
>>> On 03/16/2012 09:28 PM, Fabien Cazenave wrote:
>> OK, I understand exposing a list can be a bad idea, but we do need some
>> way to default to a relevant language, e.g. a Catalan user might prefer
>> a Spanish locale over an English one if no Catalan locale is available
>> for the document.
>>
>> We’d have to do some kind of content negotiation, like we do with HTTP
>> servers.
>
> Yes, I was assuming the UA would be able to select the language that
> fits user expectations.
In that case, I don’t have any objection concerning navigator.language.
>> way to default to a relevant language, e.g. a Catalan user might prefer
>> a Spanish locale over an English one if no Catalan locale is available
>> for the document.
>>
>> We’d have to do some kind of content negotiation, like we do with HTTP
>> servers.
>
> Yes, I was assuming the UA would be able to select the language that
> fits user expectations.
I’d even suggest to add navigator.region to get the country name (ISO
3166-1 alpha-2 code), as it could be useful for some Gaia applications
(and possibly a lot of other use cases).
--
:kazé
Robert Kaiser
Mar 21, 2012, 1:14:09 PM3/21/12
to mozilla-d...@lists.mozilla.org
Fabien Cazenave schrieb:
actually names them "tags" so if we want to make clear that it follows
that RFC, .tag would even be better...
Robert Kaiser
> Le 20/03/2012 16:42, Mounir Lamouri a écrit :
>> On 03/19/2012 06:25 PM, Fabien Cazenave wrote:
>>> So here’s the resulting API at the moment:
>>>
>>> document.mozL10n.get(key, [params])
>>> document.mozL10n.language.name (read/write property)
>>
>> Why not .code instead of .name?
>>
>
> .code then. So be it! :-)
Not wanting to play the bad guy here, but the spec of language codes
>> On 03/19/2012 06:25 PM, Fabien Cazenave wrote:
>>> So here’s the resulting API at the moment:
>>>
>>> document.mozL10n.get(key, [params])
>>> document.mozL10n.language.name (read/write property)
>>
>> Why not .code instead of .name?
>>
>
> .code then. So be it! :-)
actually names them "tags" so if we want to make clear that it follows
that RFC, .tag would even be better...
Robert Kaiser
Robert Kaiser
Mar 21, 2012, 1:24:12 PM3/21/12
to mozilla-d...@lists.mozilla.org
Fabien Cazenave schrieb:
scenes, and we really, really, really should, once the tools are usable
enough (the syntax is useable and has been agreed on before apparently
the people you work with vetoed it and so you declared it to be unstable
- but let's discuss that in appropriate forums and not here).
> • the *.properties format, already in use by most Mozilla projects.
Only that it's not. the [] with different languages is neither in the
original Java .properties format, nor in the Mozilla-style UTF-8-forced
.properties format.
The rest is very important, though. This proposal is not completely in
the right place, IMHO, as the resource format is completely
not-web-standardization-ready, and not even near to that. The LOL format
has been superior than this temporary hodgepodge for ages now, still,
let's bring it to a point where enough of your guys can agree and then
bring it into the WebAPI process by itself. Right now, we should treat
the resource file as a black box that isn't standardized and just will
have a proprietary implementation in some B2G stuff, but we should care
that it doesn't leak out to the web at large, or we'll need to support
that immature workaround for the long term - and we'll need to discuss
all its details through here.
The HTML-facing and JS-facing APIs are important and probably ready for
going through the WebAPI group, though, and we should discuss only those
here right now, not caring how .get() gets its data or how stuff is
stored in the resource file.
Robert Kaiser
> • the l20n HTML markup proposal (data-l10n-id);
> • the l20n {{arguments}} syntax in strings;
Just that I fear that stuff will break when we switch to L20n behind the
> • the l20n {{arguments}} syntax in strings;
scenes, and we really, really, really should, once the tools are usable
enough (the syntax is useable and has been agreed on before apparently
the people you work with vetoed it and so you declared it to be unstable
- but let's discuss that in appropriate forums and not here).
> • the *.properties format, already in use by most Mozilla projects.
original Java .properties format, nor in the Mozilla-style UTF-8-forced
.properties format.
The rest is very important, though. This proposal is not completely in
the right place, IMHO, as the resource format is completely
not-web-standardization-ready, and not even near to that. The LOL format
has been superior than this temporary hodgepodge for ages now, still,
let's bring it to a point where enough of your guys can agree and then
bring it into the WebAPI process by itself. Right now, we should treat
the resource file as a black box that isn't standardized and just will
have a proprietary implementation in some B2G stuff, but we should care
that it doesn't leak out to the web at large, or we'll need to support
that immature workaround for the long term - and we'll need to discuss
all its details through here.
The HTML-facing and JS-facing APIs are important and probably ready for
going through the WebAPI group, though, and we should discuss only those
here right now, not caring how .get() gets its data or how stuff is
stored in the resource file.
Robert Kaiser
Robert Kaiser
Mar 21, 2012, 1:28:33 PM3/21/12
to mozilla-d...@lists.mozilla.org
JOSE MANUEL CANTERA FONSECA schrieb:
possibilites is needed for any decent localization solution - and there
doesn't exist *any* decent localization solution at least in free
software yet at all, unfortunately, as we've learned over the years.
2) A simple approach like the one proposed here can work as a temporary
workaround until people can agree on something to bring L20n into web
apps properly, but it will never really work properly for the wide range
of languages available.
That said, the HTML- and JS-facing APIs should be stable and safe. The
resource format and tools to deliver the right thing out of the resource
format and onto an HTML presentation and into JS get() is what probably
still needs some work to have all the players agree.
Robert Kaiser
> Could you point to specific technical materials on l20n?. It seems that
> l20n proposal is 'too ambitious' for what we really need for typical apps
> on mobile phones. A simple approach like the one proposed by Caze can just
> work.
1) L20n is not too ambitious but actually something with its
> l20n proposal is 'too ambitious' for what we really need for typical apps
> on mobile phones. A simple approach like the one proposed by Caze can just
> work.
possibilites is needed for any decent localization solution - and there
doesn't exist *any* decent localization solution at least in free
software yet at all, unfortunately, as we've learned over the years.
2) A simple approach like the one proposed here can work as a temporary
workaround until people can agree on something to bring L20n into web
apps properly, but it will never really work properly for the wide range
of languages available.
That said, the HTML- and JS-facing APIs should be stable and safe. The
resource format and tools to deliver the right thing out of the resource
format and onto an HTML presentation and into JS get() is what probably
still needs some work to have all the players agree.
Robert Kaiser
Fabien Cazenave
Mar 22, 2012, 2:15:28 PM3/22/12
to Robert Kaiser, mozilla-d...@lists.mozilla.org
Should we keep ".direction" or use ".dir" instead?
:kazé
Fabien Cazenave
Mar 22, 2012, 2:15:28 PM3/22/12
to Robert Kaiser, mozilla-d...@lists.mozilla.org
Le 21/03/2012 18:14, Robert Kaiser a écrit :
Fabien Cazenave
Mar 22, 2012, 2:36:04 PM3/22/12
to Robert Kaiser
Hi Robert!
Le 21/03/2012 18:24, Robert Kaiser a écrit :
> Fabien Cazenave schrieb:
>> • the l20n HTML markup proposal (data-l10n-id);
>> • the l20n {{arguments}} syntax in strings;
>
> Just that I fear that stuff will break when we switch to L20n behind the
> scenes, and we really, really, really should, once the tools are usable
> enough (the syntax is useable and has been agreed on before apparently
> the people you work with vetoed it and so you declared it to be unstable
> - but let's discuss that in appropriate forums and not here).
Do you mean that this part of the l20n work is not stable yet?
Are these l10n-id and {{arguments}} syntaxes still likely to change?
If yes, there’s been a major misunderstanding here.
>> • the *.properties format, already in use by most Mozilla projects.
>
> Only that it's not. the [] with different languages is neither in the
> original Java .properties format, nor in the Mozilla-style UTF-8-forced
> .properties format.
It is Mozilla-style *.properties files, at least for our l10n
contributors: https://github.com/fabi1cazenave/gaia-l10n
We need a way to have multi-locale files, using [language] separators
makes sense (imho), that’s how *.ini files are built.
> The rest is very important, though. This proposal is not completely in
> the right place, IMHO, as the resource format is completely
> not-web-standardization-ready, and not even near to that. The LOL format
> has been superior than this temporary hodgepodge for ages now, still,
> let's bring it to a point where enough of your guys can agree and then
> bring it into the WebAPI process by itself. Right now, we should treat
> the resource file as a black box that isn't standardized and just will
> have a proprietary implementation in some B2G stuff, but we should care
> that it doesn't leak out to the web at large, or we'll need to support
> that immature workaround for the long term - and we'll need to discuss
> all its details through here.
The point of this thread is precisely to discuss the l10n API, not the
l10n resource format. We’ve been asking the l10n team to open the
discussion on the ”LOL” format on m.d.l10n for weeks now.
FTR, I have spent enough time writing a “LOL” parser to ensure that
every “LOL” feature could be expressed in a YAML form, a JSON form… or
even a *.properties form (i.e. in a form that would be
backward-compatible with *.properties).
> The HTML-facing and JS-facing APIs are important and probably ready for
> going through the WebAPI group, though, and we should discuss only those
> here right now, not caring how .get() gets its data or how stuff is
> stored in the resource file.
I can’t agree more with that, that’s precisely the goal of this thread.
As I wrote in a previous message, I’d also like to discuss the <link/> part:
:kazé
Le 21/03/2012 18:24, Robert Kaiser a écrit :
> Fabien Cazenave schrieb:
>> • the l20n HTML markup proposal (data-l10n-id);
>> • the l20n {{arguments}} syntax in strings;
>
> Just that I fear that stuff will break when we switch to L20n behind the
> scenes, and we really, really, really should, once the tools are usable
> enough (the syntax is useable and has been agreed on before apparently
> the people you work with vetoed it and so you declared it to be unstable
> - but let's discuss that in appropriate forums and not here).
Are these l10n-id and {{arguments}} syntaxes still likely to change?
If yes, there’s been a major misunderstanding here.
>> • the *.properties format, already in use by most Mozilla projects.
>
> Only that it's not. the [] with different languages is neither in the
> original Java .properties format, nor in the Mozilla-style UTF-8-forced
> .properties format.
contributors: https://github.com/fabi1cazenave/gaia-l10n
We need a way to have multi-locale files, using [language] separators
makes sense (imho), that’s how *.ini files are built.
> The rest is very important, though. This proposal is not completely in
> the right place, IMHO, as the resource format is completely
> not-web-standardization-ready, and not even near to that. The LOL format
> has been superior than this temporary hodgepodge for ages now, still,
> let's bring it to a point where enough of your guys can agree and then
> bring it into the WebAPI process by itself. Right now, we should treat
> the resource file as a black box that isn't standardized and just will
> have a proprietary implementation in some B2G stuff, but we should care
> that it doesn't leak out to the web at large, or we'll need to support
> that immature workaround for the long term - and we'll need to discuss
> all its details through here.
l10n resource format. We’ve been asking the l10n team to open the
discussion on the ”LOL” format on m.d.l10n for weeks now.
FTR, I have spent enough time writing a “LOL” parser to ensure that
every “LOL” feature could be expressed in a YAML form, a JSON form… or
even a *.properties form (i.e. in a form that would be
backward-compatible with *.properties).
> The HTML-facing and JS-facing APIs are important and probably ready for
> going through the WebAPI group, though, and we should discuss only those
> here right now, not caring how .get() gets its data or how stuff is
> stored in the resource file.
As I wrote in a previous message, I’d also like to discuss the <link/> part:
> • the <link/> element uses non-standard "rel" and "type" attributes
> => would that be an acceptable proposal for the HTML spec?
e.g.
> => would that be an acceptable proposal for the HTML spec?
<link rel="resource" type="application/l10n" href="data.properties" />
Do these “rel” and “type” attribute make sense?
:kazé
Robert Kaiser
Mar 22, 2012, 3:01:09 PM3/22/12
to mozilla-d...@lists.mozilla.org
Fabien Cazenave schrieb:
bikeshedding. ;-)
> Should we keep ".direction" or use ".dir" instead?
I don't think there's an established standard for that, so I don't care
too much which one we set. This changes automatically sourced from the
selected language (tag), right?
Robert Kaiser
> Sounds like a good reason to use .tag.
I guess it would be a tiny bit more correct, yes. Sorry for the
bikeshedding. ;-)
> Should we keep ".direction" or use ".dir" instead?
too much which one we set. This changes automatically sourced from the
selected language (tag), right?
Robert Kaiser
Robert Kaiser
Mar 22, 2012, 3:10:33 PM3/22/12
to mozilla-d...@lists.mozilla.org
Fabien Cazenave schrieb:
along with this and that switching to a proper resource format later
might need us to change this again as until then it will have been
firmly connected with a specific resource standard. I might be
over-cautious there, though.
>>> • the *.properties format, already in use by most Mozilla projects.
>>
>> Only that it's not. the [] with different languages is neither in the
>> original Java .properties format, nor in the Mozilla-style UTF-8-forced
>> .properties format.
>
> It is Mozilla-style *.properties files, at least for our l10n
> contributors: https://github.com/fabi1cazenave/gaia-l10n
The [tag] parts are non-standard and so it falls through in every
parsing attempt by an existing parser for .properties. It's a new,
non-standard extension to the format.
> We need a way to have multi-locale files, using [language] separators
> makes sense (imho), that’s how *.ini files are built.
This is not the .ini format, though. You could make it that, but then it
wouldn't be .properties. ;-)
> The point of this thread is precisely to discuss the l10n API, not the
> l10n resource format.
OK, that's good, then.
> FTR, I have spent enough time writing a “LOL” parser to ensure that
> every “LOL” feature could be expressed in a YAML form, a JSON form… or
> even a *.properties form (i.e. in a form that would be
> backward-compatible with *.properties).
Sure, it would never follow any of those standards fully, it would
always resemble it mostly but break it in some obvious and some subtle
ways. Exactly because of that the choice was to use something that is a
*different* format, so to not have parsers for it be extension to
existing parsers than then break in subtle ways or fall over completely.
But this is a discussion for wherever the resource format discussion is
going on, let's take it out of here until we have something we all can
be happy with.
>> The HTML-facing and JS-facing APIs are important and probably ready for
>> going through the WebAPI group, though, and we should discuss only those
>> here right now, not caring how .get() gets its data or how stuff is
>> stored in the resource file.
>
> I can’t agree more with that, that’s precisely the goal of this thread.
> As I wrote in a previous message, I’d also like to discuss the <link/>
> part
Er, sure, that's part of the HTML-facing part, right, and so within what
I said? I meant let's keep the actual format (including the file
extension and precise MIME type) of the resource files out of the webapi
discussion for now (as so far we only have a temporary solution and are
still working on consensus on a long-term one).
Robert Kaiser
> Do you mean that this part of the l20n work is not stable yet?
> Are these l10n-id and {{arguments}} syntaxes still likely to change?
> If yes, there’s been a major misunderstanding here.
No, I had some fear that we are establishing a different resource format
> Are these l10n-id and {{arguments}} syntaxes still likely to change?
> If yes, there’s been a major misunderstanding here.
along with this and that switching to a proper resource format later
might need us to change this again as until then it will have been
firmly connected with a specific resource standard. I might be
over-cautious there, though.
>>> • the *.properties format, already in use by most Mozilla projects.
>>
>> Only that it's not. the [] with different languages is neither in the
>> original Java .properties format, nor in the Mozilla-style UTF-8-forced
>> .properties format.
>
> It is Mozilla-style *.properties files, at least for our l10n
> contributors: https://github.com/fabi1cazenave/gaia-l10n
parsing attempt by an existing parser for .properties. It's a new,
non-standard extension to the format.
> We need a way to have multi-locale files, using [language] separators
> makes sense (imho), that’s how *.ini files are built.
wouldn't be .properties. ;-)
> The point of this thread is precisely to discuss the l10n API, not the
> l10n resource format.
> FTR, I have spent enough time writing a “LOL” parser to ensure that
> every “LOL” feature could be expressed in a YAML form, a JSON form… or
> even a *.properties form (i.e. in a form that would be
> backward-compatible with *.properties).
always resemble it mostly but break it in some obvious and some subtle
ways. Exactly because of that the choice was to use something that is a
*different* format, so to not have parsers for it be extension to
existing parsers than then break in subtle ways or fall over completely.
But this is a discussion for wherever the resource format discussion is
going on, let's take it out of here until we have something we all can
be happy with.
>> The HTML-facing and JS-facing APIs are important and probably ready for
>> going through the WebAPI group, though, and we should discuss only those
>> here right now, not caring how .get() gets its data or how stuff is
>> stored in the resource file.
>
> I can’t agree more with that, that’s precisely the goal of this thread.
> As I wrote in a previous message, I’d also like to discuss the <link/>
> part
I said? I meant let's keep the actual format (including the file
extension and precise MIME type) of the resource files out of the webapi
discussion for now (as so far we only have a temporary solution and are
still working on consensus on a long-term one).
Robert Kaiser
Fabien Cazenave
Mar 22, 2012, 4:38:58 PM3/22/12
to Robert Kaiser, fantasai, Henri Sivonnen
Le 22/03/2012 20:10, Robert Kaiser a écrit :
> Fabien Cazenave schrieb:
> Fabien Cazenave schrieb:
>> The point of this thread is precisely to discuss the l10n API, not the
>> l10n resource format.
>
> OK, that's good, then.
>
Agreed. :-)
>> l10n resource format.
>
> OK, that's good, then.
>
>>> The HTML-facing and JS-facing APIs are important and probably ready for
>>> going through the WebAPI group, though, and we should discuss only those
>>> here right now, not caring how .get() gets its data or how stuff is
>>> stored in the resource file.
>>
>> I can’t agree more with that, that’s precisely the goal of this thread.
>> As I wrote in a previous message, I’d also like to discuss the <link/>
>> part
>
> Er, sure, that's part of the HTML-facing part, right, and so within what
> I said? I meant let's keep the actual format (including the file
> extension and precise MIME type) of the resource files out of the webapi
> discussion for now (as so far we only have a temporary solution and are
> still working on consensus on a long-term one).
There’s no l10n resource standard yet (though gettext and properties are
well known), and I don’t think we have to wait for one before thinking
of a proper <link/> syntax: standardizing an l10n format should be a
separate effort, imho.
We don’t have to propose any file extension for this <link/> proposal.
We do have to propose a MIME type, but it doesn’t have to match the file
extension (see audio/video resources, for instance). And we have to
propose a meaningful “rel” attribute, which again doesn’t have to match
the file extension.
Therefore, I believe that:
<link rel="resource" type="application/l10n" href="data.properties" />
<link rel="LOL" type="text/LOL" href="data.lol" />
and that we should discuss it now in an open thread, as we are already
using <link rel="resource"/> elements in Gaia apps anyway.
I’d like to get some input from our “standards” guys (cc’ing Henri and
Fantasai) on this. If m.d.webapi is not suitable to discuss that, please
suggest another web-standard-oriented group.
Cheers,
:kazé
Fabien Cazenave
Mar 22, 2012, 5:33:38 PM3/22/12
to Robert Kaiser, Mounir Lamouri
http://en.wikipedia.org/wiki/IETF_language_tag
Le 22/03/2012 20:01, Robert Kaiser a écrit :
> Fabien Cazenave schrieb:
>> Sounds like a good reason to use .tag.
>
> I guess it would be a tiny bit more correct, yes. Sorry for the
> bikeshedding. ;-)
>
That’s what this thread is about. :-)
I first proposed "mozL10n.language" for that, mostly to mirror
"navigator.language", but it's becoming a bit more complex.
That’d be:
mozL10n.language.tag (read-write)
mozL10n.language.direction (read-only)
mozL10n.language.get()
Does this look correct? Mounir?
>> Should we keep ".direction" or use ".dir" instead?
>
> I don't think there's an established standard for that, so I don't care
> too much which one we set. This changes automatically sourced from the
> selected language (tag), right?
>
> Robert Kaiser
Yes, .direction (read-only) changes automatically when .tag is set.
:kazé
Le 22/03/2012 20:01, Robert Kaiser a écrit :
> Fabien Cazenave schrieb:
>> Sounds like a good reason to use .tag.
>
> I guess it would be a tiny bit more correct, yes. Sorry for the
> bikeshedding. ;-)
>
I first proposed "mozL10n.language" for that, mostly to mirror
"navigator.language", but it's becoming a bit more complex.
That’d be:
mozL10n.language.tag (read-write)
mozL10n.language.direction (read-only)
mozL10n.language.get()
Does this look correct? Mounir?
>> Should we keep ".direction" or use ".dir" instead?
>
> I don't think there's an established standard for that, so I don't care
> too much which one we set. This changes automatically sourced from the
> selected language (tag), right?
>
> Robert Kaiser
:kazé
Mounir Lamouri
Mar 23, 2012, 6:40:26 AM3/23/12
to dev-w...@lists.mozilla.org
On 03/22/2012 10:33 PM, Fabien Cazenave wrote:
> http://en.wikipedia.org/wiki/IETF_language_tag
>
> Le 22/03/2012 20:01, Robert Kaiser a écrit :
> http://en.wikipedia.org/wiki/IETF_language_tag
>
> Le 22/03/2012 20:01, Robert Kaiser a écrit :
>> Fabien Cazenave schrieb:
>>> Sounds like a good reason to use .tag.
>>
>> I guess it would be a tiny bit more correct, yes. Sorry for the
>> bikeshedding. ;-)
>>
>
>>> Sounds like a good reason to use .tag.
>>
>> I guess it would be a tiny bit more correct, yes. Sorry for the
>> bikeshedding. ;-)
>>
>
> That’s what this thread is about. :-)
> I first proposed "mozL10n.language" for that, mostly to mirror
> "navigator.language", but it's becoming a bit more complex.
>
> That’d be:
>
> mozL10n.language.tag (read-write)
> mozL10n.language.direction (read-only)
>
> mozL10n.language.get()
>
> Does this look correct? Mounir?
language.tag looks odd to me... tag in this context would make me think
> I first proposed "mozL10n.language" for that, mostly to mirror
> "navigator.language", but it's becoming a bit more complex.
>
> That’d be:
>
> mozL10n.language.tag (read-write)
> mozL10n.language.direction (read-only)
>
> mozL10n.language.get()
>
> Does this look correct? Mounir?
of an HTML element. I'm not sure if we should have a name that fits what
l10n geeks would assume to see or something web developers would
understand. Though, I don't really want to bikeshed here...
--
Mounir
Fabien Cazenave
Mar 23, 2012, 7:04:40 AM3/23/12
to Mounir Lamouri
FTR, that’s why I proposed .language and .direction at the beginning:
document.mozL10n.language (read-write)
document.mozL10n.direction (read-only)
At least, "document.mozL10n.language" would be consistant with
"navigator.language": in both cases, ".language" refers to the same kind
of language tag/code.
In fact I’m not sure it makes any sense at all for ".direction" to be a
property of ".language" instead of .mozL10n.
I agree 'tag' is misleading, I hadn't thought of HTML tags. I’d prefer
this API to be intuitive for web developers rather than for l10n experts.
:kazé
Mounir Lamouri
Mar 23, 2012, 11:02:55 AM3/23/12
to dev-w...@lists.mozilla.org
On 03/23/2012 12:04 PM, Fabien Cazenave wrote:
> My I bikeshed, too?
> FTR, that’s why I proposed .language and .direction at the beginning:
>
> document.mozL10n.language (read-write)
> document.mozL10n.direction (read-only)
Given that we are speaking of the language's direction, I prefer to put
> My I bikeshed, too?
> FTR, that’s why I proposed .language and .direction at the beginning:
>
> document.mozL10n.language (read-write)
> document.mozL10n.direction (read-only)
.direction inside .language but I know some people don't care that much
about that kind of considerations. I wouldn't try to have .language and
.direction for consistency.
Should we write a specification for that or are we expecting to have a
new version of the API very soon for l20n?
--
Mounir
Robert Kaiser
Mar 27, 2012, 3:48:33 PM3/27/12
to mozilla-d...@lists.mozilla.org
Mounir Lamouri schrieb:
"L20n API" right away for everything the HTML/JS side is seeing, and
making the actual L20n code an implementation detail, mostly bound to
the resource format, which will be a temporary non-standard for the
moment and be replaced with a hopefully standardizable L20n format later.
Robert Kaiser
> Should we write a specification for that or are we expecting to have a
> new version of the API very soon for l20n?
No, we are trying (at least if I understand kaze correctly) to use the
> new version of the API very soon for l20n?
"L20n API" right away for everything the HTML/JS side is seeing, and
making the actual L20n code an implementation detail, mostly bound to
the resource format, which will be a temporary non-standard for the
moment and be replaced with a hopefully standardizable L20n format later.
Robert Kaiser
0 new messages