Closed Bug 706661 Opened 11 years ago Closed 10 years ago

Create L10n project review template.

Categories

(Mozilla Localizations Graveyard :: Documentation, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gueroJeff, Assigned: gueroJeff)

References

()

Details

Create using https://wiki.mozilla.org/Security/ReviewTemplate as an example but more fleshed out. not as bare bones.

See this conversation below: 
chofmann:the security page is pretty barebones, and we won't want to duplicate the goal of the feature section...
[9:51pm]chofmann:atleast I don't thing we do...
[9:52pm]chofmann:content will need to be translated... where the content lives... how its integrated into the build process...
[9:52pm]chofmann:what kind of content will need to be translated... where the content lives... how its integrated into the build process...
[9:52pm]chofmann:those are the basic sections
Pike: chofmann: I don't think we can safely say that we'll translate content where it is
[9:56pm] chofmann: we might want to have two of these templates.. one for client software and one for web.
[9:56pm] Pike: mobile kinda proved the contrary

Additionally, there is an etherpad doc that Milos and Pascal have.
I took a slightly different approach to this. Rather than a review template I sought to document the process of starting a L10n program for a new project, in addition to a template that serves as a form used by both the project requester and l10n-drivers to document the project's scope and most everything involved in incorporating that project into the overall L10n workflow. That's what I interpreted to be the primary need. 


Here is the main page, which will become easily accessible by anyone looking for it: https://wiki.mozilla.org/L10n:NewProjects

Here is the template: https://wiki.mozilla.org/Template:L10n:ProjectRequestForm

They're not entirely complete, as there are still some parts of the process that I'm not entirely clear on, or particular recommendations that someone more experienced with this might make. Overall, I feel like it is a very manageable workflow. 

What do you all think?
Status: NEW → ASSIGNED
I volunteer to not be part of the process :-) Or rather, I don't know jack about web l10n.

Anywho. Do we know which problem we're solving? Honest question. I sense more than one.
Also, how does this process blend in to processes folks like the web production guys are putting up?

For the request form, I guess which questions need to be asked and which we can drop is something I can better comment on when I know what we're trying to achieve.

No target locales, IMHO. It's just making people think they can cut corners. No budget either, the wiki pages are intended to be public, I guess.
(In reply to Axel Hecht [:Pike] from comment #3)
> I volunteer to not be part of the process :-) Or rather, I don't know jack
> about web l10n.
The intent is for this to be all inclusive for both applications and web l10n.

> 
> Anywho. Do we know which problem we're solving? Honest question. I sense
> more than one.
This was brought up in response to the Firefox Live project and the BrowserID projects that recently required l10n but the process for including their projects in the workflow needed more organization.
> Also, how does this process blend in to processes folks like the web
> production guys are putting up?
Good question, which I don't have an answer to. Anyone?
> 
> For the request form, I guess which questions need to be asked and which we
> can drop is something I can better comment on when I know what we're trying
> to achieve.
> 
> No target locales, IMHO. It's just making people think they can cut corners.
> No budget either, the wiki pages are intended to be public, I guess.
But it also allows smaller l10n teams the option to not participate if their workloads are already full. Also, I'll get rid of the budget question.
Let's not try to create a process that includes everything. I'm scared of those.

So in terms of problems to solve, I see two by now:

- you got a project, where are the giants on which shoulders you can build?
- how should localization teams gauge on wether to participate in your project?
(In reply to Axel Hecht [:Pike] from comment #5)
> Let's not try to create a process that includes everything. I'm scared of
> those.
Booga booga :-) What makes you scared of those? One standard process would make it more inclusive and easier to follow. 

> 
> So in terms of problems to solve, I see two by now:
> 
> - you got a project, where are the giants on which shoulders you can build?
Sort of. I would add, "I have a project, what considerations do I need to make in its design for l10n? Can it be localized in the timeframe I want it localized in? How can I expect to fit it within the overall L10n workflow? Who are my contacts on the l10n team to help me figure this stuff out?"
> - how should localization teams gauge on wether to participate in your
> project?
Well, that produces another question: who decides on which locales participate: the l10n teams or the project owners? The original wiki page made it seem like the project owners are in charge of that.
Sorry for the lag. I have a few comments wrt https://wiki.mozilla.org/L10n:NewProjects :

> If your project is a web project, file a bug under the web project's Bugzilla
> component, include the URL to your completed L10n request form, & add Pascal
> Chevrel, Milos Dinic, and web@localization.bugs to the bug. 

The bug should be filed against Websites>Other and stas@mozilla.com should be in CC, too.

> Set up the L10n infrastructure for your project (e.g., project locale metrics,
> repos, localization notes within copy, etc.).
>
>    Choose the localization format.

Not sure whether you meant engagement here, but about localization format, that's something webdev and l10n-drivers should discuss. Also, for anything outside of mozilla.org/firefox/ , we prefer gettext(.po), so as to utilize our tools(ie. Verbatim). Of course, if there are some major downsides to using that, we can talk about it.

>    We'll ask IT to set up a locale staging sites.

We shouldn't bother about this, as this is something webdev and IT should be working on. We're there to say whether it's done properly or not(eg. sll locales are showing proper content, translations are pulled from VCS or not, language selector is working or not...).

Overall, this page looks decent.
Closing this bug. Process appears to be moving smoothly. So far The Den and the Olympics projects have been processed using this process. As additions or subtractions need to be made, we can re-open if need be. Thanks everyone!
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Mozilla Localizations → Mozilla Localizations Graveyard
You need to log in before you can comment on or make changes to this bug.