Closed Bug 1290947 Opened 10 years ago Closed 9 years ago

Breakdown: Devtools.html localization changes

Categories

(DevTools :: General, enhancement, P1)

Product:
DevTools
Component:
General
Version:
46 Branch
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Iteration:
51.2 - Aug 29

People

(Reporter: bgrins, Assigned: jdescottes)

References

Details

(Whiteboard: [devtools-html])

To make localization work in a content privileged environment, we need to move all access out of dtd files and into JS (starting with inspector, toolbox, webconsole), and then shim Services.strings to work without chrome.
Flags: qe-verify-
Summary: Breakdown bug for devtools.html localization changes → Breakdown: Devtools.html localization changes
Whiteboard: [devtools-html]
Priority: -- → P2
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Iteration: --- → 51.1 - Aug 15
Priority: P2 → P1
I would like to get some early feedback on what I understood so far. The localization migration will be split in 2 parts : 1. Migrate the localization done using DTD files 2. Migrate the localization done dynamically using Services.strings.createBundle Part1: DTD files @Brian: I saw in the phase 2 document a short exchange between you and Paul Rouget about using DTD files with XHTML documents. You said you couldn't get it to work when testing. I wonder what is the difference between what you tested and something like aboutdebugging.xhtml, which is using a DTD for localization? How can I replicate the same testing environment? Before diving into migration strategies, I'd like to make sure we can't stick with DTDs for static markup. Part2: Services.strings I would like to leverage the LocalizationHelper util already used in some devtools files. Assuming we can't migrate our properties files to js/json files, I see the following migration path here: 2.1: create a loader to read raw/properties files 2.2: migrate LocalizationHelper to read, parse properties files 2.3: migrate modules still using Services.strings to use Localization helper Let me know if you have any feedback on this!
Flags: needinfo?(bgrinstead)
I spent some time going through the documentation and code for l20n.js (https://github.com/l20n/l20n.js just in case) and it looks like this could be a good fit for us. I will try to prototype using the web runtime, and see if I can get anywhere.
(In reply to Julian Descottes [:jdescottes] from comment #1) > I would like to get some early feedback on what I understood so far. > > The localization migration will be split in 2 parts : > 1. Migrate the localization done using DTD files > 2. Migrate the localization done dynamically using > Services.strings.createBundle > > Part1: DTD files > @Brian: I saw in the phase 2 document a short exchange between you and Paul > Rouget about using DTD files with XHTML documents. You said you couldn't get > it to work when testing. I wonder what is the difference between what you > tested and something like aboutdebugging.xhtml, which is using a DTD for > localization? How can I replicate the same testing environment? > > Before diving into migration strategies, I'd like to make sure we can't > stick with DTDs for static markup. I was trying with an xhtml file on a local webserver and could never get it to load an external dtd. If I copied entities in directly it works, like so: <!DOCTYPE html [ <!ENTITY foo "Foo"> ]> <html xmlns="http://www.w3.org/1999/xhtml"> &foo; </html> But if I do this then I get "XML Parsing Error: undefined entity": file.xhtml: <!DOCTYPE html [ <!ENTITY foo "Foo"> <!ENTITY % aboutdebuggingDTD SYSTEM "aboutdebugging.dtd"> %aboutdebuggingDTD; ]> <html xmlns="http://www.w3.org/1999/xhtml"> &aboutdebuggingDTD.foo; </html> aboutdebuggging.dtd: <!ENTITY aboutDebugging.fullTitle "Debugging with Firefox Developer Tools"> Maybe you can figure something out there - whatever we do should work in a normal tab without requiring chrome / resource loading. > Part2: Services.strings > > I would like to leverage the LocalizationHelper util already used in some > devtools files. > Assuming we can't migrate our properties files to js/json files, I see the > following migration path here: > > 2.1: create a loader to read raw/properties files > 2.2: migrate LocalizationHelper to read, parse properties files > 2.3: migrate modules still using Services.strings to use Localization helper > > Let me know if you have any feedback on this! Yes, that's similar to what I was thinking.
Flags: needinfo?(bgrinstead)
The localization team is actively working on bringing l20n to Firefox as whole. You can read about the project[1] on the wiki. It sounds like by the end of the year, they will have good infrastructure in place for Firefox UI to use l20n, for localizers to translate the files, etc. I would say l20n is definitely the future for Firefox, but if we make a change in DevTools _right now_ it could be too early to make use of the infrastructure they are about to build. I would suggest talking to the localization team about our needs. [1]: https://wiki.mozilla.org/L20n/Firefox
Axel, Zibi: We are migrating devtools from XUL to HTML, with the end-goal of being able to load them in a normal browser tab (no chrome privileges etc...). For localization, it means we can't rely on DTDs in XUL/XHTML, or use Services.strings to create bundles from properties files. It would be nice if we could use this occasion to directly migrate to l20n, which brings a few questions : - 1: I think the l20n web runtime can be a good fit for us. Can we start using it right now or is it too soon? Also is the infrastructure & tooling ready for localizers to start localizing FTL files? - 2: one concern regarding l20n is the fact that the API is heavily asynchronous, which means migrating our existing code will be a bit costly. Is a synchronous API planned here ? - 3: when do you think the Firefox UI will start migrating to l20n? If the migration is coming soon, we should start using l20n asap, regardless of the migration cost considerations from question 2.
Flags: needinfo?(l10n)
Flags: needinfo?(gandalf)
In reverse notation: re 3), we're aiming to land the first pieces of migrated Firefox UI early November. We're working on various fronts towards that. Performance, UI correctness, builds, repacks, migration of existing localizations, localization tools, dashboards. https://wiki.mozilla.org/L20n/Firefox is our project page. The big step after that is going to be scale, in terms of code ported, reviewers educated, developers learning, and localizers starting to take advantage of the new possibilities to fix long-standing bugs. Re 2), we talked about sync vs async and the pros and cons quite a bit with Joe in London. Yes, there's quite a difference between coding for l20n and the regular sync l10n codes. But there are also benefits to reap, which are worthwhile, IMHO. Synchronous APIs are possible, but I'd look at them in the scope of us trying to deliver on desktop, and also Android after that. Re 1), the runtime is ready to use, it's async API surface is stable. gandalf is currently working on timing on how things happen at page load to make this work great. One big item is that we need to work together to not *start* localizing devtools.html. My suspicion is that most of the UI is going to have strings we know, and we need to port them forwards. This is a process we're developing for desktop this month. I don't know the full details yet, but as we're changing how parameters get into strings, it's more involved than just copy and paste.
Flags: needinfo?(l10n)
Flags: needinfo?(gandalf)
I think we should ignore l20n for the time being. Axel is right about the need to convert the properties files. It's also massively compounded by the demands of changing every single string lookup to be async. I think we should consider using l20n when we've completed moving to HTML (so we're not refactoring 2 things at the same time) and we have good async/await support, and we understand the performance implications.
Depends on: 1294184
Depends on: 1294185
Depends on: 1294186
Depends on: 1294188
Depends on: 1294189
> 2.1: create a loader to read raw/properties files You can use require("raw!devtools/path/to/whatever") to get a file's contents. E.g., https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/theme.js#15
Depends on: 1294220
Note, the ask about doing automatic conversion stands even if you're converting from DTD to .properties.
Thanks for all the information Axel! Given our timeframe I tend to agree with Joe here, let's do a simple migration first to allow devtools.html to work, and let's migrate to l20n in a second separate step. Looking forward to this! (In reply to Axel Hecht [pto-Aug-30][:Pike] from comment #9) > Note, the ask about doing automatic conversion stands even if you're > converting from DTD to .properties. Correct. I suppose your comment was referring to properties/DTD -> FTL conversion. Is any process ready yet for DTD -> properties conversion or do we need to wait here? gandalf: I see Axel is on PTO, maybe you can answer here?
Flags: needinfo?(gandalf)
> Correct. I suppose your comment was referring to properties/DTD -> FTL conversion. Is any process ready yet for DTD -> properties conversion or do we need to wait here? I don't think you need to wait, but I don't think we have any process for DTD->Properties because we did not perform and do not plan to perform any of such migration. :matjaz (NI'ed) may have some more recent experience with converting between formats, but generally we're currently aiming at converting DTD/Prop -> FTL.
Flags: needinfo?(gandalf) → needinfo?(m)
(In reply to Julian Descottes [:jdescottes] from comment #10) > (In reply to Axel Hecht [pto-Aug-30][:Pike] from comment #9) > > Note, the ask about doing automatic conversion stands even if you're > > converting from DTD to .properties. > > Correct. I suppose your comment was referring to properties/DTD -> FTL > conversion. Is any process ready yet for DTD -> properties conversion or do > we need to wait here? My assumption is that :Pike would like us to write a script to convert DTD to properties format which can be run on the l10n repos to avoid retranslation (assuming the string values are kept the same). I am not aware of existing tools for this purpose, so I think :Pike is requesting that we make something. In past experiences with string moves and such, we've usually sent an email to dev-l10n prior to landing a big change like this, and you could link to such a script in that message so that the localizers can run it on their own repos. The l10n repos[1] are pretty straightforward to navigate. [1]: http://hg.mozilla.org/l10n-central
Important clarification: most locales work on mozilla-aurora, not l10n-central. So you will land on central, and that script will be run on merge day a few weeks after that.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11) > > Correct. I suppose your comment was referring to properties/DTD -> FTL conversion. Is any process ready yet for DTD -> properties conversion or do we need to wait here? > > I don't think you need to wait, but I don't think we have any process for > DTD->Properties because we did not perform and do not plan to perform any of > such migration. > > :matjaz (NI'ed) may have some more recent experience with converting between > formats, but generally we're currently aiming at converting DTD/Prop -> FTL. Sadly no experience with mass DTD -> properties conversion here. I don't know if it's useful at all, but in Pontoon we use a fork of gandalf's Silme library, which contains DTD and properties parsers and serializers: https://github.com/mathjazz/silme/
Flags: needinfo?(m)
Iteration: 51.1 - Aug 15 → 51.2 - Aug 29
Depends on: 1265887
Breakdown is finished, all necessary bugs should now be created and tracked for devtools html phase 2.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.