1958707 - Make webconsole experimental strings less hacky

Status: NEW

(Localization Infrastructure and Tools :: General, enhancement)

Description

[Nick Alexander :nalexander [he/him]]

Right now, we have an untranslated Fluent string for some webconsole technical details: see https://searchfox.org/mozilla-central/rev/a0c761cb7958c0c9a3e7e34d944f12b56e0737fa/devtools/server/actors/webconsole/commands/experimental-commands.ftl. The reason that this file does not show up to localizers is, I believe, twofold:

1. It's not covered by l10n.toml files in devtools/;
2. It's omitted from the directories listed "by hand" in https://searchfox.org/mozilla-central/rev/a0c761cb7958c0c9a3e7e34d944f12b56e0737fa/browser/locales/Makefile.in#48-71.

While trying to figure out how to replace some or all of that Makefile goo, I ran across the fact that this string is the only untranslated Fluent string not exposed to localizers. If it were not a special case, we would be closer to not needing the hand-curated list, a small simplification to the existing system.

It's worth noting that the string has been updated 4 times in its 1.5 year lifetime -- not a lot, but more than most.

:flod, :eemeli: could we just expose this string with notes about not localizing, like we do with branding strings? Are there other ways of not exposing this to localizers, perhaps with new affordances (ignore?) in l10n.toml files?

Comment 1

[Francesco Lodolo [:flod]]

(In reply to Nick Alexander :nalexander [he/him] from comment #0)

It's worth noting that the string has been updated 4 times in its 1.5 year lifetime -- not a lot, but more than most.

It was changed 3 more times in the span of a few weeks before that, which led to that string being removed from localization
https://phabricator.services.mozilla.com/D196830#6534733

I can't answer on why this would need a modified makefile, given that browser and toolkit have plenty of "preview" files not exposed for localization: https://searchfox.org/mozilla-central/search?q=locales-preview&path=jar.mn&case=false&regexp=false

I ran across the fact that this string is the only untranslated Fluent string not exposed to localizers

As mentioned above, there are plenty of Fluent strings not exposed to localizers. Did you mean "devtools strings", or strings in general?

Comment 2

[Eemeli Aro [:eemeli]]

As Flod mentions, we do have a bunch of messages in "preview" FTL files that are not, and should not be, localized.

Given our existing choice of keeping L10n files in locales/en-US/ directories, I would prefer not changing that or expanding the set of such directories unless there's a good reason for doing so.

OTOH, we could make it easier to include non-localized or read-only messages and resources among the existing ones. We've done some work here on developing a common metadata schema, a part of which could already be applied to Fluent via moz.l10n tooling. With this approach, a resource or a message could have a @do-not-translate (or similar) semantic comment attached to it, which would exclude it from Pontoon, and copy the value from the source locale during the L10n build.

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Eemeli Aro [:eemeli] from comment #2)

OTOH, we could make it easier to include non-localized or read-only messages and resources among the existing ones. We've done some work here on developing a common metadata schema, a part of which could already be applied to Fluent via moz.l10n tooling. With this approach, a resource or a message could have a @do-not-translate (or similar) semantic comment attached to it, which would exclude it from Pontoon, and copy the value from the source locale during the L10n build.

To be clear and set expectations, because I feel this can be interpreted too optimistically.

This is work that has only been discussed. It's not planned, and would likely require additional engineering given the team's bandwidth.

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Francesco Lodolo [:flod] from comment #1)

(In reply to Nick Alexander :nalexander [he/him] from comment #0)

It's worth noting that the string has been updated 4 times in its 1.5 year lifetime -- not a lot, but more than most.

It was changed 3 more times in the span of a few weeks before that, which led to that string being removed from localization
https://phabricator.services.mozilla.com/D196830#6534733

Roger.

I can't answer on why this would need a modified makefile, given that browser and toolkit have plenty of "preview" files not exposed for localization: https://searchfox.org/mozilla-central/search?q=locales-preview&path=jar.mn&case=false&regexp=false

I ran across the fact that this string is the only untranslated Fluent string not exposed to localizers

As mentioned above, there are plenty of Fluent strings not exposed to localizers. Did you mean "devtools strings", or strings in general?

Ah, you're right, there are plenty of preview strings not exposed to localization. I think the weirdness here is that this string is the only one that doesn't get processed by the moz.l10n system in the regular way, i.e., point 2. in the original comment.

This can be normalized without a great deal of effort; I'll try to do so.

(In reply to Eemeli Aro [:eemeli] from comment #2)

Given our existing choice of keeping L10n files in locales/en-US/ directories, I would prefer not changing that or expanding the set of such directories unless there's a good reason for doing so.

Would you be okay with a devtools/server/locales/en-US location for this string? It's weird that it's not following suit...

Comment 5

[Eemeli Aro [:eemeli]]

(In reply to Nick Alexander :nalexander [he/him] from comment #4)

Would you be okay with a devtools/server/locales/en-US location for this string? It's weird that it's not following suit...

You know, I think we could do so, and add its path here. That way it should effectively work the same as it does currently, except for a browser console logging of the missing message in the current locale, before falling back to the en-US source.

Bryan, Flod, thought on this? The approach could in theory work for all Firefox preview strings, thanks to the new L10n build tooling creating an empty file for missing ones, which means that we always do per-message rather than per-context fallback.

Comment 6

[Francesco Lodolo [:flod]]

I'm not a fan of this approach because it's more opaque and blurs ownership boundaries.

Right now, it's easy to track when a file becomes localizable, since everything is self-contained within mozilla-central. With this new setup, we’d lose that clarity — just looking at mozilla-central wouldn’t tell us whether a file is being localized. It also shifts the responsibility to engineers to flag when a file is ready, but the decision point ends up in a separate repository that engineers shouldn't interact with. On top of that, we'd need to maintain the ignore list manually and in a separate location, or build automation around it, which feels like overengineering.

Comment 7

[Bryan Olsson [:bolsson]]

Would you be okay with a devtools/server/locales/en-US location for this string? It's weird that it's not following suit...

I'd want to avoid any path with /locales/en-US/ for files not exposed to localization. Right not it's simple when reviewing phabricator patches to differentiate on that factor to understand whether strings are being exposed or not. Any other path that makes sense I'd be okay with.

Otherwise I'll just re-double what Flod mentioned - this adds more potential risk without much upside if we could normalize the string without much effort as Nick mentions.

Comment 8

[Francesco Lodolo [:flod]]

One more reason not to do it: not everything is using moz.l10n yet.

compare-locales has no concept of ignoring files, so any localizable file in the l10n source repository is treated as "must be localized". This would also affect the Japanese team, which is still working against the repo and using compare-locales for error checking.

Comment 9

[Eemeli Aro [:eemeli]]

(In reply to Francesco Lodolo [:flod] from comment #6)

Right now, it's easy to track when a file becomes localizable, since everything is self-contained within mozilla-central. With this new setup, we’d lose that clarity — just looking at mozilla-central wouldn’t tell us whether a file is being localized. It also shifts the responsibility to engineers to flag when a file is ready, but the decision point ends up in a separate repository that engineers shouldn't interact with. On top of that, we'd need to maintain the ignore list manually and in a separate location, or build automation around it, which feels like overengineering.

In theory, we could also keep the .l10n-ignore file in mozilla-central, and sync it from there to firefox-l10n-source. But as you and Bryan have a clear preference for not changing the current setup, there's no reason to pursue this alternative approach further. We should therefore also keep experimental-commands.ftl outside locales/en-US/ paths.