Closed Bug 794059 Opened 12 years ago Closed 12 years ago

Need to be able to activate pages on production on a per locale basis

Categories

(www.mozilla.org :: Bedrock, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pascalc, Assigned: pmac)

References

(Blocks 1 open bug)

Details

(Whiteboard: u=localizer c=l10n p=3 )

We are starting to have more ans more bedrock-powered localized content and content that target a set of locales and not all Firefox locales (FirefoxOS locales, Firefox for Android locales, regional campaigns that target specific geography...)

Currently a push to production of a page is whole or nothing, on the php site, I would associate an url with an array of locales and redirect other locale requests to en-US.

We need something similar on the python site, the inmmediate would be for the contribute page that I would like to activate for French, Spanish, Portuguese, Bengali, Serbian and Croatian by the end of the months and later activate locales as we are ready both in terms of translation and in terms of community involvement (people answering emails).

Setting priority as Major because I don't have a workaround I could use as a temporary solution for this one

Could this be in the next sprint?

Thanks
Making p=3 because IMHO implementation research is needed on the code side.
Summary: [bedrock] need to be able to activate pages on production on a per locale basis → Need to be able to activate pages on production on a per locale basis
Whiteboard: u=localizer c=l10n p=3 [sb-sprint]
Whiteboard: u=localizer c=l10n p=3 [sb-sprint] → u=localizer c=l10n p=3
Any news on this one?
Assignee: nobody → pmac
I'm working on this now. I understand that we'll need to be able to activate views (urls) with sets of locales. Does this mean that for a url that we haven't set any locales for, that it should be implied that the set is ('en-US'), and would cause all requests to that url to go to the en-US version? Or if we haven't set any locales for a page, should we just let it ride and if there are translations for that page, then it'll work?
Flags: needinfo?(pascalc)
It is preferable that we display pages either fully localized or fully in English, no mix. I think the easy way (which was what we were doing in PHP most of the time), was to redirect to the en-US page if a page that is restricted to a set of locales is not activated yet.
Flags: needinfo?(pascalc)
Blocks: 793754
I was chatting with Ben Sternthal about this and he came up with what I believe is a simple and elegant solution to this:

He proposed that since we already have a .lang file for every template, that "activation" of a locale for a page could be as easy as indicating in the .lang file for that locale and template that it's active. This keeps all the l10n information close to the translations, allows people who already have permission to push translations to prod to handle locale activation per page, and allows for activation outside of a bedrock push.

I propose that the activation comment be the first line of the file, and have the following format:

## active ##

I added so many # symbols because I want it to stand out and be obvious. I don't see a need to have it be more complex than this. We could do "## active=true ##" to allow for other states, but that seems like overkill, and all you'd need to do to deactivate is delete the line or change it slightly. For example:

## inactive ##

Would not be active, simple because it doesn't exactly match the correct line, but it may a good way to indicate that it's been purposefully deactivated.

Further comments and suggestions very welcome.
The syntax is fine for me
Note: This PR should not be merged before making sure the appropriate .lang files have been updated with the `## active ##` header.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 808570
Depends on: 815573
You need to log in before you can comment on or make changes to this bug.