Closed Bug 773322 Opened 12 years ago Closed 12 years ago

Allow for locales to set their own auto-response preferences in Want to help? form

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: davidwboswell, Assigned: giorgos)

References

()

Details

Opening bug to track updating the Want to help? form to allow for locales to set their own auto-response preferences.

For background, bug 756093 is about localizing the Want to help? form to allow for it to be embedded in localized versions of the Get Involved page.  Currently localized versions of the form will be inheriting the preferences from the English version though which is a mix of auto and manual replies.  Details at:

https://wiki.mozilla.org/Mozilla.org/Contribute/Point_people#By_Functional_Area

We should be able to allow a given locale to set their own preferences -- some may want all auto-responses or all manual responses or a mix depending on their areas of expertise, volume of emails, etc.
David,

this is is a fair point, but I'd argue this shouldn't block the initial l10n release of the page. Given localizers will be able to do with auto-responses whatever they see appropriate, I'd assign this to some of the future milestones.

As for the implementation, we can do this by hard-coding per-language settings in our code, or we could create config-like file for localizers where we'd move recipients for email inquiries and add a simple setting for each area to be switched between auto-response enabled or disabled.

Of course, we can as well add such a setting in regular main.lang files, but given that some of this stuff shouldn't be touched by just anyone who may or may not be familiar with what said settings may affect, we should really consider having it in separate place.

Stas, Pascal, Chofmann, any thoughts?
I agree with David on the reasoning, different locales have different needs, some locales have plenty of activities and qualified volunteers and will want to tailor the responses, other locales are a one man effort and they will probably want to get a specific response on the specific area that will remove burden on their shoulders.

The people who have write access to our svn l10n repo are our core localizers who have signed a committer's agreement, therefore I don't see any problem in storing their preferences in their repo alongside their .lang files in a settings file (just as product localizers have access to the productization data for Firefox which is a lot more touchy data since it involves external partners).

That said, I agree that perfection is the enemy of the good. This is already a technically complex page to localize and we already have met several bugs in the platform exposed that this page (the latest today being bug 774232) and I would prefer us to focus on shipping a first iteration in July that is maybe not good enough for a large scale localization with all the parameters that come with dealing with diverse communities, but good enough for FISL in Spanish and Portuguese.
(In reply to Milos Dinic [:Milos] from comment #1)
> this is is a fair point, but I'd argue this shouldn't block the initial l10n
> release of the page.

Agreed - this doesn't need to block the initial release.  We'll just need to make sure the PT and ES Reps involved with handling responses know about this issue and have the information available to know which areas are receiving auto-responses and which aren't.
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
So this is done in https://github.com/mozilla/bedrock/pull/322.

Auto-responses are sent whenever there is a file present for the locale.

For the 'coding' area, if en-US does not want an auto-response but pt-BR wants one, pt-BR just has to create a file in pt-BR/templates/mozorg/emails/coding.txt.
Resolving as the pull request for this is merged.

Once it's live we can verify.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.