639869 - Implementation of a localization module

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 1

[Axel Hecht [:Pike]]

I have zero context, as such, I'm clueless.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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:
http://hg.mozilla.org/qa/mozmill-tests/file/default/shared-modules/utils.js#l305
http://hg.mozilla.org/qa/mozmill-tests/file/default/shared-modules/utils.js#l340

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: 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.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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 5

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

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.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 7

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

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.

Comment 8

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

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.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Landed as:
https://github.com/geoelectric/mozmill-api-refactor/commit/1fd63471e03aaf37a3861b7303ac55e665af443d