Option to switch developer tools GUI to English
Categories
(DevTools :: General, enhancement, P3)
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".
Comment 1•7 years ago
|
||
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.
Comment 2•7 years ago
|
||
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!
Updated•6 years ago
|
Comment 3•2 years ago
|
||
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
Comment 4•2 years ago
|
||
It wouldn't be too bad to build some UI around this.
You can install the langpack for en-US
via:
AddonManager.getInstallForURL
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.
Comment 5•2 years ago
|
||
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.
Comment 6•2 years ago
|
||
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.
Comment 7•2 years ago
|
||
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.
Comment 8•2 years ago
|
||
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?
Comment 9•2 years ago
|
||
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 10•2 years ago
|
||
Comment 11•2 years ago
•
|
||
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.
Comment 12•2 years ago
|
||
(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.
Comment 13•2 years ago
|
||
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?
Comment 14•2 years ago
|
||
I'm translating to "de" as local builds are in en-US already...
Comment 15•2 years ago
|
||
I'm translating to "de" as local builds are in en-US already...
Updated•2 years ago
|
Comment 16•2 years ago
|
||
My main blockers in order to proceed with this feature/patch would be to:
- Confirm that the following APIs are actively maintained and will be kept running in the future:
-
The following rest endpoint: https://services.addons.mozilla.org/api/v4/addons/language-tools/?app=firefox&type=language&appversion=104.0
-
The following langpack hostings: https://addons.mozilla.org/firefox/downloads/file/3998558/romanian_language_pack-104.0.2buildid20220902.153754.xpi
So that it is fine using the following bits to force installing the en-US langpack for DevTools:
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`
- 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.
Comment 17•2 years ago
|
||
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.
Comment 18•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•