Internationalization is the process of designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing the code needed.

Since the transition from DTD/properties to L20n is a massive undertake, we want to initially keep close control over which pieces are being localized using it.
In order to be able to land the APIs but control how they're used, we'll want to introduce a whitelist that prevents new FTL files from being added to the build without :pike, :stas and :gandalf knowledge.
This whitelist will be removed once we gain confidence in stability of the new API.

:ted, can you help me figure out the best location for this?
Basically, we'd like to ensure that people don't start playing with FTL files without our knowledge.
The easiest way I imagine this to work is to hook us into some build/packaging step and filter out all *.ftl files against some maintained whitelist.
At the top of the whitelist we'd have a note saying to not add anything there without :pike's permission.

Comment on attachment 8910809[details][diff][review]bug1394891.diff
Review of attachment 8910809[details][diff][review]:
-----------------------------------------------------------------
There are a few problems in this patch. Also, I'd prefer to have this on mozreview in the next iteration.
::: hghooks/mozhghooks/check/prevent_ftl_changes.py
@@ +47,5 @@
> + def name(self):
> + return 'ftl_check'
> +
> + def relevant(self):
> + return True
This should do the same as the try config hook,
return self.repo_metadata['firefox_releasing']
Also, should have tests to make sure that that happens.
@@ +53,5 @@
> + def pre(self):
> + pass
> +
> + def check(self, ctx):
> + if any(f.endswith('.ftl') for f in ctx.files()):
Should this be any ftl file, or just those exposed to localizers? Thinking about tests in particular.

Thanks Axel. Updated the patch to your review.
> Should this be any ftl file, or just those exposed to localizers? Thinking about tests in particular.
We talked with Axel about this and decided to keep the check applied to all .ftl files including tests.

Zibi, thinking about this patch I realized that we're changing tree rules, effectively.
Do we have approval to do so? I suspect it'd be a good idea to have a stakeholder of tree rules to review this patch, too.
(Not that I'd know who that is.)

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11)
> Dave, can you advise here? Axel asked me to write this to keep a tight
> control over .ftl files in mozilla-central during the pilot phase in 58 and
> 59.
As far as I'm concerned you folks own localisation and hence requiring your review for changes to pieces of localisation for a temporary period seems fine. That said I think you should post to dev-platform spelling out the plan so that everyone is aware of the reasons why and we can hear if there are any objections.

yes, parse_requal_reviewers() is the best way to parse reviewers.
> But then again, I don't find any users of that ad-hoc
parse_requal_reviewers() was added after most of the hooks.
they should be updated at some stage :)

Excellent! Thank you Byron and Axel!
I updated the patch to use commitparser (way cleaner!) and added the IS_FIREFOX_REPO (I have no idea why the test didn't fail before, but it fo sure did now without it).
Re-requesting review :)

This just got deployed as a ride-along with another deployment. If it causes problems, it is easy enough to disable (by commenting out references to prevent_ftl_changes in hghooks/mozhghooks/extensions.py in v-c-t.

The original announcement for this change said:
"By All Hands we hope to be ready to remove the hook and enable everyone to use the new API. In the months to come, we'll be writing guidelines, tutorials, blog posts and other forms of prose[1] to get you all familiar with what changes and how to review patches for the new system. "
It was posted just over a year ago, so 2 all-hands ago. When are we intending to turn off this commit hook?

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #27)
> The transition takes longer than expected, and at this moment I believe we
> should wait for two events:
> - Fluent enabled on startup path (bug 1441035)
> - Fluent 0.8 release (1.0 beta)
I would also like to see more tooling, for example to check FTL syntax sanity, before we remove the hook limitation.

You need to log in
before you can comment on or make changes to this bug.