Closed Bug 844167 Opened 11 years ago Closed 11 years ago

Update en-GB Get Involved email templates

Categories

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

Product:
www.mozilla.org
Component:
L10N
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kinger, Assigned: flod)

References

Details

en-GB is missing some email templates, e.g. localization.txt. Pascal, if I am not mistaken I believe you told me to copy from en-GB for new locales. I have been doing this.

This was the cause of bug 823536, and after this is fixed I will have to update all the new locales I created off en-GB since then that are missing these templates.

How can we keep these better in sync moving forward? One solution is to copy from en-US and not en-GB.
In addition to localization.txt being missing from the en-GB repository, it also looks like there may be a naming conflict with the auto-response for Firefox Support inquiries.

In the Bedrock repository, the auto-response email is named issues.txt but in the en-GB repository it is issue.txt.  I'm assuming this means those auto-responses aren't getting sent because the file name is not what the script is expecting.

I scanned through the auto-response file names of other locales and they seem to be a mix of issues.txt and issue.txt -- I suppose some localizers caught this and manually changed it.

For example:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/locales/es-ES/templates/mozorg/emails/issues.txt?view=log

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/locales/pt-BR/templates/mozorg/emails/issue.txt?view=log
I'd also like to update the en-GB repository with a coding.txt auto-response template that locales can use (Josh manually sends these for English coding inquiries so there's no coding.txt file on Bedrock, but that shouldn't force locales to manually respond).

We can take the text for that from here:

https://wiki.mozilla.org/Contribute/Canned_responses#Coding
Process question: With three separate proposed changes to the en-GB repository in this bug now, would it make sense to make this a tracking bug and set three different blocking bugs for the specific changes?
(In reply to David Boswell from comment #4)
> Process question: With three separate proposed changes to the en-GB
> repository in this bug now, would it make sense to make this a tracking bug
> and set three different blocking bugs for the specific changes?

No, I think we can keep track in this bug.

I'm still wondering though if we should by pass en-GB and just always copy from en-US?

Pascal?
(In reply to Brian King [:kinger] from comment #5)
> I'm still wondering though if we should by pass en-GB and just always copy
> from en-US?

One potential wrinkle with going straight from en-US is if we put a coding.txt file in the en-US version so localizers can use the text we want to make sure that it doesn't get sent out for en-US coding inquiries.

In general, going directly from en-US sounds like it may solve the syncing problems, but I'm not familiar with all of the l10n best practices, so will be interesting to hear Pascal's thoughts.
Assignee: pascalc → francesco.lodolo
Comment 2 (issue.txt vs issues.txt) has been solved several weeks ago when I became aware of the problem and renamed all files. Some locales had their templates in the wrong folder too.

Right now en-GB contains all templates from the current version of Bedrock except for coding.txt (which doesn't exist on Github).

Current situation (8 locales with auto-replies):
* fr, nl, pt-BR, ru: 11 templates, missing localization.txt
* sr: 12 templates, no coding.txt
* es-ES, hr, zh-TW: 13 templates, they already have a coding.txt

My suggestion would be to create a coding.txt and copy all updated auto-replies to localizers who still haven't started working on them. Then just send a message out to the five teams that have less templates. Since these templates are optional, I'm not even sure that opening bugs depending on the main [xx] Localize Get Involved page would make sense. Opinions?
(In reply to Francesco Lodolo [:flod] from comment #7)
> My suggestion would be to create a coding.txt and copy all updated
> auto-replies to localizers who still haven't started working on them.

That makes sense to me.  It would be good to give localizers an option to create a localized coding auto-response.  

I'm assuming if we add a coding.txt in the en-GB directory then that wouldn't change anything with Josh's workflow for the en-US inquiries?

I'm also copying Josh on this bug to see if he has any thoughts on the content for a coding auto-response template for locales.
My base template is this:

>Hi,
>I'm Josh, one of many Firefox developers. Glad to hear from you! Feel free to have a look at http://whatcanidoformozilla.org if you're interested in joining a particular project or team. Meanwhile, I'll tell you about some general opportunities for writing code for Firefox.
>
>To get started with the codebase, have a look at http://developer.mozilla.org/En/Introduction.
>
>If you need any help, you can obtain it on IRC. I recommend visiting #introduction, which is specifically for newcomers. See http://irc.mozilla.org for how to access it.
>
>Feel free to contact me anytime if you're having any problems! I'm jdm on IRC, or just josh@joshmatthews.net.
>
>Happy hacking,
>Josh
(In reply to David Boswell from comment #8)
> I'm assuming if we add a coding.txt in the en-GB directory then that
> wouldn't change anything with Josh's workflow for the en-US inquiries?

That's my understanding of the structure. en-US templates are not taken from SVN but from Bedrock directly, so having a coding.txt in en-GB won't change anything.

Is Josh's text ok for you? Not sure if we should let the reply as it is or make it more impersonal.
I've updated the email templates for all locales still not working on them (r117053).

While doing so I discovered that the wiki page wasn't really up to date. There are 4 other locales currently using autoreplies: de, id, sq, zh-CN.

So, the updated situation is 12 locales with auto-replies:
* de, fr, id, nl, pt-BR, ru, sq, zh-CN: 11 templates, missing localization.txt
* sr: 12 templates, no coding.txt
* es-ES, hr, zh-TW: 13 templates, they already have a coding.txt
(In reply to Francesco Lodolo [:flod] from comment #10)
> Is Josh's text ok for you? Not sure if we should let the reply as it is or
> make it more impersonal.

Flod, if there are some l10n best practices about making things more impersonal so they're easier to localize, feel free to edit that coding template as needed before adding it to the en-GB repo.
(In reply to David Boswell from comment #12)
> Flod, if there are some l10n best practices about making things more
> impersonal so they're easier to localize, feel free to edit that coding
> template as needed before adding it to the en-GB repo.

Proposed text below.

----

Hi,
we're glad to hear from you! Feel free to have a look at http://whatcanidoformozilla.org if you're interested in joining a particular project or team. Meanwhile, here's some general opportunities for writing code for Firefox.

To get started with the codebase, have a look at http://developer.mozilla.org/En/Introduction.

If you need any help, you can obtain it on IRC. I recommend visiting #introduction, which is specifically for newcomers. Visit http://irc.mozilla.org for information on how to access it.

Happy hacking!

---
(In reply to Francesco Lodolo [:flod] from comment #13)
> Proposed text below.

Looks good to me.  It's Josh's call though since it's his text.
As long as it doesn't become the default for en-US, it's fine with me, as long as s/here's/here are/.
Thanks Josh,
file added in r117111.

> As long as it doesn't become the default for en-US.

Besides en-US being only on Github (bedrock), I realized that en-GB is never pushed to stage or production, that locale exists only on stage, so no problem there.

Added file coding.txt to locales still not working on templates in r117112

I'll task with Pascal next week to understand the best way to deal with existing locales with 11 or 12 templates.
Talked with Pascal, we agreed to add the templates and ping localizers in a couple of weeks if they don't notice the new files.

r117157
Added coding.txt and localization.txt: bn-BD, de, ff, id, nl, pt-BR, ru, sq, zh-CN.
Added coding.txt: hi-IN, ms, sr, vi.

Updated templates for fr, en-ZA since they were still in English and out of date (also updated the wiki for fr, they're currently not using autoreplies).

I believe this bug can be closed now. David?
Flags: needinfo?(dboswell)
Flod, thanks for sorting all this out and following up with people about the changes.

Before we close, what are your thoughts on avoiding having en-US and en-GB get out of sync again going forward?
Flags: needinfo?(dboswell)
(In reply to David Boswell from comment #18)
> Before we close, what are your thoughts on avoiding having en-US and en-GB
> get out of sync again going forward?

I see two scenarios here.

New area of interest
That's easy to spot because we'll also have a new string in the .lang file. However we need to have a template ready to copy over to other locales (e.g. unlike what happened with coding.txt), at least we're sure localizers have at least a schema to follow.

Updates to existing templates
TBH I don't know how we can spot these, apart from checking the history on Github
https://github.com/mozilla/bedrock/tree/master/bedrock/mozorg/templates/mozorg/emails

And even if a template change, there's no way to tell if the same change should be applied to existing locales. To give you an example, I completely rewrote the original localization.txt for Italian, so from now on I'm not really interested in en-US updates.

I guess the important thing is to check that en-GB templates are up to date before copying them to a new locale.
(In reply to Francesco Lodolo [:flod] from comment #19)
> I guess the important thing is to check that en-GB templates are up to date
> before copying them to a new locale.

That sounds like the best option.  

If there's a major change to an en-US template that would be an issue for all locales, even those that rewrote their replies, we can deal with that as needed instead of trying to automate it.

Closing as fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.