Need a way in bedrock to easily activate new locales on production (like on the php site)

RESOLVED FIXED

Status

www.mozilla.org
Bedrock
P1
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: pascalc, Assigned: jbertsch)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=dev c=l10n p=)

(Reporter)

Description

5 years ago
I briefly talked about that with Rik last Friday.

Currently, on the PHP site, activating a new locale on production is a simple merge from the initial commit on trunk (adding the locale code in arrays in includes/langconfig.inc.php) to the production tag.

We have new locales coming (about 5 for sure for Q4) and we regularly add new locales supported by Firefox. There can be a long time or a very short time between the moment we start a locale on the website and the moment we publish it because the factor for the push to production is the availability of a localized version of Firefox.

Since the localized download pages are currently on the PHP site, this is not a blocker, but if we want to migrate the Firefox download page to the python template soon, we need to have the same flexibility regarding publishing new locales as we had with php.

This is actually more a SVN vs GIT workflow than a PHP vs Python, I just don't know how we can do it with git since all merges are for full branches and not single commits. I want localizers to have access to the staging server and this one is based on the master branch, but if we add a locale to master, it will be pushed to production with the next push of master before Firefox localization is ready. If I create a branch for the locale, the localizer and myself don't have a staging server to test his work, if we create a demo server for new locales, that means that depending on the locale (old locale or new locale), I will have to give different instructions. The creation of a branch for locales also means that I will have the extra workload of constantly merging master into that branch which is something I didn't have to do with subversion.

Maybe having two lists in base.py would work, one list would be all the locales we have working on the staging site, and one list would be the locales we don't want activated yet on production.
(Reporter)

Updated

5 years ago
Blocks: 775269
Assignee: nobody → pmac
Priority: -- → P1

Updated

5 years ago
Whiteboard: u=dev c=l10n p=
(Assignee)

Updated

5 years ago
Assignee: pmac → jbertsch
(Assignee)

Comment 1

5 years ago
Resolved per Chris More:  We Pascal have ability to launch per locale pages now with Ben's solution by adding comments to .lang files. Pmac already coded it.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Perhaps pascal can chime in here, but I don't think the .lang file comments solution addresses this bug. This is about adding new languages to the site, not translations. We have a list of locale codes in our settings file that we support. I believe he wants a way to edit this list.

:pascalc please let us know whether you still need this.
(Reporter)

Comment 3

5 years ago
Yes, I still need that
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
After investigating I've found that we have this today. We have two lists in settings: DEV_LANGUAGES and PROD_LANGUAGES. PROD_LANGUAGES is manually maintained and should only be modified when a locale is ready for stage and prod. DEV_LANGUAGES is dynamically populated from all of the folders in the locales repo (http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/locales/). New folders added to that repo should automatically work on dev and the demo servers, but won't on stage and prod. It may require us to do a fake push to cause apache to restart to pickup the new lang due to the setting only looking at the folders when the server starts, but this is very easy with chief.

:pascalc ping me on IRC if you have further questions on how this works.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.