756093 - Update Want to help? form to support additional languages

Status: RESOLVED FIXED

(www.mozilla.org :: L10N, defect, P1)

Description

[David Boswell]

In order to localize the Get Involved page we'll also need to update the 'Want to help?' form to handle additional languages.  

Modifying the existing form might not be the best way to scale this to handle dozens of locales, but in the short-term it will work for adding one or two locales.  See bug 743746 for plans for adding the first two non-English locales for this page.

The relevant files in github are:

The location of the current auto-responses in use
https://github.com/mozilla/bedrock/tree/master/apps/mozorg/templates/emails

The location of the form elements
https://github.com/mozilla/bedrock/blob/master/apps/mozorg/forms.py

The location of the form logic
https://github.com/mozilla/bedrock/blob/master/apps/mozorg/views.py

James Long and Steven Garrity ported this form to Bedrock, so we can also ask them any questions we have about how to update things to support additional languages.

Comment 1

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Looking at the files I assume some changes are needed to add l10n support for them, since the l10n function is loaded:

from l10n_utils.dotlang import _

But it not used by the strings which are hardcoded. For them to be localizable, they should be used like this one:

policy_txt = _('I agree to the <a href="%s">Privacy Policy</a>')

We can also use the same for "localizing" the emails, if the email strings are localizable, we can change them easily per locale if needed (A comment for each one would help to clarify which person does what).

(Also there are some /en-US/ hardcoded urls)

Comment 2

[William Duyck [:fuzzyfox]]

Idea: The form should have a hidden field that knows which local the current page is being viewed in... then on the backend when the form is submitted it should be a simple matter of using this information to determine which txt file to use when sending the auto response back. This would allow for the auto response to be localized and in situations where the localized version of the auto response is not available the english can be sent back so there is always a response of some kind. 

Maybe an alternate version of the english can be sent back requesting the recipient to localize the email for us... that way they can jump straight into the project with something meaningful and useful... two birds with one stone in some situations.

Comment 3

[David Boswell]

FYI, I just filed bug 773322 about allowing locales to set their own auto-response preferences for the Want to help? form.

Comment 4

[Anthony Ricaud (:rik)]

Two behaviours for the recipient of the inquiry have already been done by Giorgos and Milos.

Giorgos version: https://github.com/mozilla/bedrock/commit/7b109f980874da43da31174b2ebf1975c48d4ebf
This send the form to the default address for the area of interest + one other for each locale.

Milos version: https://github.com/milossh/bedrock/commit/d6e4ce56bf466fc249f2705c943e219fa925a1ab
This lets localisers choose the address they want to receive it on.

In both situations, this is also sent to [e-mail].

What is the desired behaviour here?

Comment 5

[David Boswell]

For desired behavior, for inquiries sent from a localized version of the page, emails should be sent both to the [e-mail] list as well as the relevant point person for that locale.  Point people documented at:

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

There is also some documentation about the workflow differences in the form between EN and non-EN versions at

https://wiki.mozilla.org/Contribute/Inquiry_Workflow

If this doesn't fully answer the question, let me know and I'll provide more information.

Comment 6

[Milos Dinic [:Milos]]

David,

There's one big difference between Giorgos' and my patch. Giorgos fixed it so that we add the email recipents(other than `Point People`) for each locale directly in our code, and my patch allows localizers to do that via .lang files they have direct access to.

So, main question here should be: do we want to allow localizers to change additional recipients or do we do that from within our code on github?

Comment 7

[David Boswell]

(In reply to Milos Dinic [:Milos] from comment #6)
> So, main question here should be: do we want to allow localizers to change
> additional recipients or do we do that from within our code on github?

My thought is that it seems best to allow localizers to control this and to also keep things as easy to update as possible, so I'd favor the lang files.

For instance, keeping this in the code on Github would mean that a change would need to wait for a site release to go live.  That seems like a lot of overhead and potentially several days of waiting to have a change go into effect.

If there are some disadvantages to this approach we should consider, let me know.

Comment 8

[Ben (:bensternthal)]

A +1 to Milos's approach, specifically because this keeps localized content in the same place.

Comment 9

[Milos Dinic [:Milos]]

Than this is already in our code. One thing that keeps me from resolving this one is to, per Pascal's request, add email addresses in separate contribute.lang file.

Comment 10

[Ben (:bensternthal)]

Milos, can you clarify what Pascal's request is? I do not see a comment from him in this bugs -> thanks!

Comment 11

[Milos Dinic [:Milos]]

Ben,

So, we'll extract default email addresses that inquiries are sent to, to an .lang file, to enable localizers to just translate them, hence change the recipient. Now, by default in my patch, those email addresses are extracted to main.lang file, whereas Pascal wants them to be in separate, contribute.lang file.

Comment 12

[Anthony Ricaud (:rik)]

This not clear to me yet.

Let's not talk about the technical implementation yet. (.lang files or bedrock is irrelevant to the use-case) Let's talk use-cases first.

Someone goes to the 'de' version of the page and wants to contribute to QA. Who should receive this inquiry? [e-mail] is a given. The point person for the locale is a given. Question 1: Should [e-mail] receive it too?

Question 2: What should we do for locales that don't have a point person?

Comment 13

[David Boswell]

(In reply to Anthony Ricaud (:rik) from comment #12)

Good point about focusing on use cases.

> Someone goes to the 'de' version of the page and wants to contribute to QA.
> Who should receive this inquiry? [e-mail] is a given. The
> point person for the locale is a given. Question 1: Should
> [e-mail] receive it too?

My thought is that only the locale point person is emailed directly here.

The reasoning is that inquiries in German will probably be noise on qa-contribute since most people there probably don't speak German.

If someone from QA wants to keep an eye on non-EN QA inquiries they can always monitor the contribute list by subscribing or accessing the web archive or establishing a close working relationship with the German locale point person.  

The last option is preferred since we'd want the functional area point people and locale point people coordinating closely.

I think this is the best option with the current infrastructure we have.  If we had a lead generation tool that let people pick the inquiries they want to receive, that would be ideal.
 
> Question 2: What should we do for locales that don't have a point person?

We won't localize the Get Involved page unless there is a point person for that locale who will field the inquiries.

Comment 14

[Anthony Ricaud (:rik)]

Pull request for this at https://github.com/mozilla/bedrock/pull/322

Comment 15

[Ben (:bensternthal)]

Pull request looks closed, I suggest resolving these once that's done. We can verify when its on prod.

Comment 16

[Ben (:bensternthal)]

Pull request is closed, resolving. Will test the localized functionality and email routing.

Comment 17

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/d41980b08df6db097a69e09938e513db07c6bd90
Update "Want to help?" form to support additional languages

fix bug 756093

- Move logic to email_contribute.py
- Refactored data structures to conform a bit more to DRY
- Remove newsletter options on non 'en' locales (fix bug 770606)
- Tests ! (fix bug 780911)
- Email backend in DEV environments writes to the console to avoid
unnecessary email sending
- PEP8 cleanups
- Fixes a dotlang test that depended on en-US

Comment 18

[Anthony Ricaud (:rik)]

This has been pushed to production.