Open Bug 1377737 Opened 7 years ago Updated 2 years ago

Option to switch developer tools GUI to English

Categories

(DevTools :: General, enhancement, P3)

54 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: mozilla, Unassigned)

Details

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170613080547

Steps to reproduce:

I have openend the Developer Tools.


Actual results:

The developer tools GUI appears in my browser's language (German). Although this is a nice intention, it makes the tool almost unusable:

- Some technical terms have been translated (e.g. "Speicher"). This is not necessary for developers, as they need to be trained in reading English. It is rather a source for confusion because of ambiguities. "Speicher" could mean both "storage" and "memory", so what does it actually mean?

- It is not possible to find help on the Internet. If you search for the German words, you won't find many of the English help resources on the internet. It is also difficult to ask for help in English, since I don't know the original English wording of the button.

- English tutorials cannot be reproduced, because the GUI looks totally different in other languages.


Expected results:

There should be a configuration option: "Use Developer Tools in English".
Severity: normal → enhancement
Component: Untriaged → Developer Tools
Bringing this to Bryan's attention. I think Richard makes a good point, but we also consider localization of tools as a competitive advantages. Being able to switch DevTools' locale independently of Firefox's local could be a nice thing. What do you think?

Triaging as P3 for now as this isn't something we'll be working on soon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(clarkbw)
Priority: -- → P3
Yes, I'd like to tackle this in Q4 and I think part of that will mean giving developers an option in our setting to choose their UI language.  We've previously run a survey about this before and found exactly what you said how its easier to work with the rest of the content on the web if the tools are in english.  However about 1/2 the developers we surveyed really enjoyed having the tools in their language. Making it easier to switch and perhaps easier to search for things should be priorities.  

Also we can file a bug just for the translation of that term if there's a better one you can think of. 

Thanks!
Flags: needinfo?(clarkbw)
Product: Firefox → DevTools

Greg, how difficult it would be to implement support for switching DevTools UI (and only DevTools UI) to English? Do we have the right platform API available? Can we dynamically download English strings (when they are not avaailalble in non-english builds)?

Honza

Flags: needinfo?(gtatum)

It wouldn't be too bad to build some UI around this.

You can install the langpack for en-US via:

AddonManager.getInstallForURL

See: https://searchfox.org/mozilla-central/rev/108c7843696fdf951083889d6fb858953139be96/intl/locale/LangPackMatcher.jsm#168-173

The langpack URL can be retrieved via (I think):

AddonManager.getAddonByID("langpack-en-US@firefox.mozilla.org")

You will also need to prompt for a restart, since DevTools hasn't migrated to Fluent, and it doesn't respect the intl:app-locales-changed event. The custom Fluent loader that DevTools uses needs to be updated to load in the new strings, since it's using it's own custom code to do that. I can link where that lives if you need it too.

Let me know if you need any more information.

Flags: needinfo?(gtatum)

Wouldn't installing this langpack translate the whole Firefox UI to en-US?
If not, then, how to start using the installed langpack only for devtools?

More concretely, in DevTools, for old fashion .properties we load them from here:
https://searchfox.org/mozilla-central/rev/3aaca0a12a2d1463da54933bdbdae2f06fead06f/devtools/shared/l10n.js#62

      propertiesFile = require("raw!" + url);

Where url is devtools/client/locales/dom.properties and require will load the file like this:
https://searchfox.org/mozilla-central/rev/3aaca0a12a2d1463da54933bdbdae2f06fead06f/devtools/shared/loader/loader-plugin-raw.jsm#27-36
where uri will typically be resource://devtools/client/locales/dom.properties.

Would the langpack override resource://devtools/client/locales/ folder automagically?
Or should we query an hand crafted url to hook into the langpack content?

Now, may be all this would be significantly simplier where we use fluent, but I know very little about fluent yet.

Flags: needinfo?(gtatum)

It's been a few months since I was looking at this code, so hopefully my memories are accurate here.

Wouldn't installing this langpack translate the whole Firefox UI to en-US?
If not, then, how to start using the installed langpack only for devtools?

Installing a langpack and using the langpack are two different things. The main browser has langpack it prefers, but it can fallback to other strings. In DevTools you could manage your own primary locale if you wanted to prefer en-US. In short this would be ["en-US", ...Services.locale.appLocalesAsBCP47].

DevTools doesn't support live language switching since it's managing its own life cycle for the language packs, and doesn't hook into the rest of Firefox. Once you restart the browser, the DevTools should use a newly installed langpack. Fluent will make the switching simpler since there is only one localization to switch. The Fluent code is here:

https://searchfox.org/mozilla-central/source/devtools/client/shared/fluent-l10n/fluent-l10n.js

This will need to listen to the "intl:app-locales-changed" event, and respect it once it changes. The easiest way to test that this is done correctly is to change the pseudo-locale.

Properties files can be a bit more complicated, at least when using the typical string bundle loaders, especially since they can be loaded in the parent process into immortal shared memory. The only way to invalidate that memory is through a full restart. I haven't looked too deeply into the DevTools loaders for this case.

Would the langpack override resource://devtools/client/locales/ folder automagically?

I would assume if you invalidated the previous request, and re-requested after an app locale change you would get the new string bundle. If you wanted an alternate DevTools locale configuration (where you prefer "en-US"), you would have to teach the loader to load the proper locale to bypass the typical locale resolution mechanism. So yes, this would be much simpler if it were just Fluent which is architected to understand and listen to locale changes.

Let me know if I can clarify any points here.

Flags: needinfo?(gtatum)

Ah, I re-read my comments about requesting a restart. This would at least simplify the invalidation step. So yes, you would probably need to craft custom URLs to bypass the normal resolution scheme for properties files. To simplify, you could have a checkmark to prefer "en-US", and only if that bool pref is set, then specifically load the en-US locales.

The first step would be to have a mechanism that works with a Firefox restart. It is a reasonable requirement and simplifies lots of things.

For everything around fluent, this should be mostly about tweaking this line:
https://searchfox.org/mozilla-central/rev/3aaca0a12a2d1463da54933bdbdae2f06fead06f/devtools/client/shared/fluent-l10n/fluent-l10n.js#31
and prepend en-US to the locales array as you just suggested?

For .properties, I can help draft a plan around the loader and its internal cache as I know it quite well.
But it is pretty unclear what the URL of the properties should be.
Today, the .properties are fetched from resource://devtools/client/locales/dom.properties URLs.
I imagine this just defaults to the locale shipped in the omni.jar.
Do you know what should be the new URL to fetch the en-US version? (or any arbitrary locale)
I imagine the DevTools .properties files will be in the langpack add-on.
If yes, should we use a jar: URL to manually refer to these addon files, or the add-on maps the files to a more convenient URL?

For everything around fluent, this should be mostly about tweaking this line:

Yeah, that seems reasonable to me, as long as the langpack addon is installed it should work.

But it is pretty unclear what the URL of the properties should be.

I poked at the URL resolution a bit, and it was pretty confusing and hard to follow. Under the hood it takes a string and maps it to a file path. I'm pretty sure you can add the "en-US" into the URL somewhere and it would work... There is logic to map the locales path to an actual folder, but you can probably bypass it.

I'll attach a file tree view of an es-ES langpack I was using when testing this before.

Comment on attachment 9293521 [details]
ff-100-es-ES-langpack.txt

edit: Whoops, accidental comment. The above text file I included the mistaken command above it.

(In reply to Greg Tatum [:gregtatum] from comment #9)

I poked at the URL resolution a bit, and it was pretty confusing and hard to follow. Under the hood it takes a string and maps it to a file path. I'm pretty sure you can add the "en-US" into the URL somewhere and it would work... There is logic to map the locales path to an actual folder, but you can probably bypass it.

It looks like there is a mapping always done to a resource:// URL over there:
https://searchfox.org/mozilla-central/rev/3aaca0a12a2d1463da54933bdbdae2f06fead06f/toolkit/components/extensions/Extension.jsm#3413

For example, when I install the "de" langpack, I get dom.properties served this way:
resource://langpack-de-browser/browser/chrome/de/locale/de/devtools/client/dom.properties

So that we might be able to map URL this way:
resource://langpack-$[locale}-browser/browser/chrome/${locale}/locale/{$locale}/${pathToPropertiesFile}

You can see that we also register the langpack to the nsChromeRegistry.cpp, to register the langpack through chrome:// URLs,
but this codebase is meant to expose only one unique chrome:// URL for each file and there is an inner logic to automagically map
URL to the right locale when using a chrome://package-name/locale/ URL.
I wouldn't go this way. Or we would have to expose a convertChromeUrl() method with a "locale" argument.

Next challenge, how to compute the langpack URL?

On release, and may be beta, we might be able to use AddonRepository.getAvailableLangpacks.

const { AddonRepository } = ChromeUtils.import("resource://gre/modules/addons/AddonRepository.jsm");
const pack = await AddonRepository.getAvailableLangpacks();
const enUS = pack.find(({ target_locale }) => target_locale === "en-US");
enUS.url // install this add-on

But on nightly we will query the following URL:
https://services.addons.mozilla.org/api/v4/addons/language-tools/?app=firefox&type=language&appversion=106.0a1
which returns no available langpack, whereas there is some actually available:
https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/linux-x86_64/xpi/

Any suggestion?

I'm translating to "de" as local builds are in en-US already...

I'm translating to "de" as local builds are in en-US already...

Attachment #9293548 - Attachment is obsolete: true

My main blockers in order to proceed with this feature/patch would be to:

  1. Confirm that the following APIs are actively maintained and will be kept running in the future:
  1. See if the previously describe APIs could be made to work against Nightly builds.
    https://services.addons.mozilla.org/api/v4/addons/language-tools/ doesn't seem to work for nightly builds.
    Is that true, or I missed a partcilar way to query this URL?
    If not. Does that mean we should use another way to find the current nigtghly build's langpack? Or forget about the idea of translating nightly builds?
    In the current revision of https://phabricator.services.mozilla.com/D157338
    I'm downloading the langpack from ftp.mozilla.org:
    https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/linux-x86_64/xpi/firefox-106.0a1.de.langpack.xpi
    But that looks very brittle.

1.:

const { AddonRepository } = ChromeUtils.import("resource://gre/modules/addons/AddonRepository.jsm");
const allLangpacks = await AddonRepository.getAvailableLangpacks();
const enUSLangpack = allLangpacks.find(({ target_locale }) => target_locale === "en-US");
// install the add-on from `enUSLangpack.url`

This all should be 100% supported. Live language switching is using this in both about:preferences and about:welcome.

2:

I don't have a good answer for this. When I was doing live language switching I didn't get into the distribution and packaging part of it. I know we have translators working on Nightly, so we'll have at least some subset of strings available. I would be supportive of bringing langpack switching to Nightly, but it would require investigating who currently has knowledge in this area. I don't have any contacts in the AMO team, but we could ask the l10n team.

But that looks very brittle.

Yeah this sounds a bit risky to me for a long term solution. Perhaps it would be fine if it's just en-US and you make sure the code is reasonable if it breaks.

While localizers are working against Nightly, we don't support language packs in Nightly, because the content is not stable and things could break after an update (although Fluent makes breaks more graceful).

This could be only supported in beta and release (not Developer Edition, because of branding issues, bug 1597692).

Without actively deprecating .properties and switching completely to Fluent, which falls back to en-US at run-time, we won't be able to support language packs in Nightly.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: