Implementation of a localization module



Mozilla QA
Mozmill Tests
7 years ago
7 years ago


(Reporter: whimboo, Assigned: whimboo)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [module-refactor])


(1 attachment)

For the API refactoring of Mozmill tests we will have to add a localization module.

For now I would simply port over the existing code, but would like to get feedback if other stuff would be helpful.

Contained features:
* Retrieve entities from one or more listed DTD files
* Retrieve strings from a listed property file.

Everything necessary for the l10n test-run will follow later when we port the individual test-runs.

Axel, do you have any further information on top of the two items above?
Whiteboard: [module-refactor]

Comment 1

7 years ago
I have zero context, as such, I'm clueless.
Axel, this is part of the work from Adrian last year. In detail it has to cover everything which is related to l10n and could be useful/necessary for our Mozmill tests.

At the moment we have those two l10n related helper methods:
OS: Mac OS X → All
Hardware: x86 → All
Created attachment 519067 [details] [diff] [review]
Patch v1

Implements the l10n module with our currently existing methods to retrieve entities and properties. One thing I don't like is the handling of the stack for each time we fire an exception. Lets revise that in the refactoring round of milestone 2.
Assignee: nobody → hskupin
Attachment #519067 - Flags: review?(gmealer)
Clint and Heather, I think that we should also consider to move those 2 methods to Mozmill core. Those have been proven over time and will also help with other XUL applications.
Comment on attachment 519067 [details] [diff] [review]
Patch v1

Looks fine. Only question is whether these functions really need to be exposed (i.e. documented) for general test use?

If this will be used by the shared-mods only, you should @private the docs.
Attachment #519067 - Flags: review?(gmealer) → review+
Tests will have to use those methods if no shared module is available which covers the specific set of DTD files. Also I wouldn't mark those private because it's important to know the interface when you create a new shared module. We definitely need that documentation. 

Already asked you on IRC, when do you think we can land this module? I assume I have to wait for your remaining code to close out M1?
Go ahead and land anything with an r+ as soon as convenient.

As soon as the refactor stuff is all done, we'll call ourselves "at m1", but I'm not concerned if m2 stuff like L10N gets in there first. The only side effect is that when we snapshot m1, it'll be in the snapshot, but I don't think that's a problem.
Moving this to block the milestone. Anything listed as a primary milestone task on the wiki can go straight on the milestone. Refactors should parent to-do stuff that aren't in the main plan.
Blocks: 639544
No longer blocks: 639545
Landed as:
Last Resolved: 7 years ago
Resolution: --- → FIXED
Blocks: 641777
You need to log in before you can comment on or make changes to this bug.