[L10n] Remove en-US strings from HTML files

[Zibi Braniecki]

Hi all!

We'd like to start cleaning up the HTML sources of en-US strings.

Storing en-US strings in HTML files brings several problems:

1) It requires us to store the same strings twice, so it desyncs pretty quickly

2) It creates an illusion that your UI is localized even when some errors prevent it from happening

3) It makes grepping code harder

Because at build time we rewrite all nodes anyway, there's really no reason to keep it in the sources.

We're not sure yet if it makes sense to try to do a one-time search&replace as it may bring some noise to the diff because of lossy parse/serialize. I filed bug 1095065 to track that.

In the meantime, please, stop adding strings to HTML files and start removing the existing ones in your apps when you have a chance.

As always, questions/feedback to :stas and :gandalf on IRC or here :)

zb.

[Kevin Grandon]

This sounds like a good initiative to take. I think migrating files as we edit them is probably the best path forward here, like we are doing with jshint fixes.

Also one thing that I wanted to confirm is that this means *all html*, including HTML templates inside javascript which may have strings?

E.g., myEl.innerHTML = '<div data-l10n-id="foo">foo</foo>';

We should remove the strings in these cases as well?

Best,
Kevin

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Jim Porter]

On 11/06/2014 02:40 PM, Zibi Braniecki wrote:
> 2) It creates an illusion that your UI is localized even when some
> errors prevent it from happening

This is why I generally prefer putting ugly-but-readable strings like
"EmaiL SettingS" in the HTML. It's still obvious when something goes
awry, but it makes finding things easier (see below).

> 3) It makes grepping code harder

I'm not sure I understand this one. Wouldn't it make grepping easier?
(If, for instance, I was trying to find the part in the HTML that showed
a certain string.)

- Jim

[Zibi Braniecki]

On Thursday, November 6, 2014 12:51:57 PM UTC-8, Kevin Grandon wrote:
> This sounds like a good initiative to take. I think migrating files as we edit them is probably the best path forward here, like we are doing with jshint fixes.
>
> Also one thing that I wanted to confirm is that this means *all html*, including HTML templates inside javascript which may have strings?
>
> E.g., myEl.innerHTML = '<div data-l10n-id="foo">foo</foo>';
>
> We should remove the strings in these cases as well?

Yes, of course, that textContent just doesn't make sense since :)

zb.

[Zibi Braniecki]

On Thursday, November 6, 2014 12:58:36 PM UTC-8, Jim Porter wrote:
> On 11/06/2014 02:40 PM, Zibi Braniecki wrote:
> > 2) It creates an illusion that your UI is localized even when some
> > errors prevent it from happening
>
> This is why I generally prefer putting ugly-but-readable strings like
> "EmaiL SettingS" in the HTML. It's still obvious when something goes
> awry, but it makes finding things easier (see below).

Except that it relies on us maintaining some sync between what's in properties and what's in the source, making sure that we spot that the string has capital letters and it also makes testing harder (textContent !== 0 in marionette test is impossible).

> > 3) It makes grepping code harder
>
> I'm not sure I understand this one. Wouldn't it make grepping easier?
> (If, for instance, I was trying to find the part in the HTML that showed
> a certain string.)

It depends on what you're searching for. Finding the same string in HTML and l10n resource file and then trying to identify if it should be inserted from JS or via HTML API is confusing.

zb.

[André Jaenisch]

Commented inline.

Kevin Grandon <kgra...@mozilla.com> schrieb am Do, 06.Nov.14 12:51:

> Also one thing that I wanted to confirm is that this means *all html*, including HTML templates inside javascript which may have strings?
>
> E.g., myEl.innerHTML = '<div data-l10n-id="foo">foo</foo>';

Umm, it should probably be </div> :)

I would like to know, how to handle, say, alt-or title-attributes of images.

> ----- Original Message -----
> From: "Zibi Braniecki" <zbigniew....@gmail.com>
> To: mozilla-...@lists.mozilla.org
> Sent: Thursday, November 6, 2014 12:40:50 PM
> Subject: [L10n] Remove en-US strings from HTML files
>

> We'd like to start cleaning up the HTML sources of en-US strings.

So where do I find these now?
I'm repeatedly digging into source, if readers of my blog have questions about
Firefox OS and I do now want to bother devs/distract them from their work.

Best regards,


André Jaenisch

[Andrew Sutherland]

On 11/06/2014 03:57 PM, Jim Porter wrote:
> On 11/06/2014 02:40 PM, Zibi Braniecki wrote:

>> 2) It creates an illusion that your UI is localized even when some
>> errors prevent it from happening

> This is why I generally prefer putting ugly-but-readable strings like
> "EmaiL SettingS" in the HTML. It's still obvious when something goes
> awry, but it makes finding things easier (see below).

FTR in the email app when the l10n build or runtime mechanisms broke,
weird bugs got filed against the email app when they saw the strings.
While it's handy that any bugs were filed, if the expectation can end up
being "hey I don't see any strings at all, I'll file an l10n or build
bug instead of filing a bug against the app", that would certainly be an
improvement in my book! :)

(Noting that most of these breakages were due to the build system not
being "make -jN" safe at the time but being built that way in automated
builds. I think many of these issues have ideally been resolved and
shouldn't crop up again.)

Andrew

[Zibi Braniecki]

On Thursday, November 6, 2014 1:08:25 PM UTC-8, André Jaenisch wrote:

> I would like to know, how to handle, say, alt-or title-attributes of images.

https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/localization_code_best_practices#Do_not_use_mozL10n.get

> So where do I find these now?
> I'm repeatedly digging into source, if readers of my blog have questions about
> Firefox OS and I do now want to bother devs/distract them from their work.

So, the reality is that as a front-end developer you *are* in fact carrying both hats. You're writing UI *and* you are writing en-US localization for it.
(the same way as you are writing UI and you are writing the default CSS theme for it).

The mode of operation should probably be:

1) Identify the string you are looking for
2) Find its l10n-id in l10n resources
3) Find where this l10n-id is used

We could also, on top of pseudolocales, offer a view in which we will just show l10n-ids instead of strings in the UI, but that requires Gaia to stop relying on broken/missing-string-return-empty paradigm and it'll take some time to get to :)

zb.