Create a localization (l10n) component for Mozilla.com

RESOLVED FIXED

Status

()

bugzilla.mozilla.org
Administration
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: stephend, Unassigned)

Tracking

Details

(Reporter)

Description

8 years ago
Please create a localization component for Mozilla.com -- I watch Mozilla.com and get a ton of emails that don't pertain to me; thanks!
hmm, thoughts on a name? Should it be under Websites or Mozilla Localizations?
since we are moving from a one bug per web localization project to one web localization bug per locale, this is indeed generating a lot of bug reports so it sounds like a good idea to have a web localization bug.

I would propose:
l10n - www.mozilla.com 
(if we put it in the websites section)

or just www.mozilla.com if it is under Mozilla Localizations

I have no strong preference for one or the other, Stas, Seth do you have a preference?
Ah, that's an interesting bug :)

So currently "Mozilla Localizations" are under Client Software ("End User Products developed by mozilla.org contributors") which is not websites really, but in-product pages--yes, maybe (like firstrun or whatsnew).

I think we may want to consider a couple of solutions to a situation when a product (here "websites") becomes l10n-heavy. These are:
1. Create a 'localization' component under Websites. It will not be divided further into separate locales.
2. Create  a 'websites' component under "Mozilla Localizations". It will be created next to existing per-locale components, and will not be divided further into separate locales.
3. Use existing "Mozilla Localizations" under "Client Software" for other products without changing anything. That creates noise for people currently following their locale's component if all they want is client software.
4. Create a new classification for localization ("Mozilla Localizations") and either do (products: Products, components: Locales) or (products: Locales, components: Products). I'm not sure yet which one would be easier and for whom. The biggest disadvantage of this solution is that it requires the most work and is a really big change in the bugzilla hierarchy.

Adding l10n folks for their feedback.

Comment 4

8 years ago
(In reply to comment #3)
> 1. Create a 'localization' component under Websites. It will not be divided
> further into separate locales.

Perhaps I am not understanding, but why could we not divide into separate locales after creating the component localization?  What about a present example like the Fennec project where only a subset of locales are participating.  Won't we want the ability to select individual locales for various projects?

> 2. Create  a 'websites' component under "Mozilla Localizations". It will be
> created next to existing per-locale components, and will not be divided further
> into separate locales.

I am not sure I like this idea because, iiuc, we still cannot select specific locales for projects who have opt-ed in on various projects.


> 3. Use existing "Mozilla Localizations" under "Client Software" for other
> products without changing anything. That creates noise for people currently
> following their locale's component if all they want is client software.

Not ideal, in my opinion.  There is definitely a separation between web and product localizers in some of our more robust communities. So, individuals may choose to only follow product or web.

> 4. Create a new classification for localization ("Mozilla Localizations") and
> either do (products: Products, components: Locales) or (products: Locales,
> components: Products). I'm not sure yet which one would be easier and for whom.
> The biggest disadvantage of this solution is that it requires the most work and
> is a really big change in the bugzilla hierarchy.

I guess it's unprecedented to be able to select from a list of products since "Mozilla localizations" is the existing product and Bugzilla doesn't allow other choices.  This might be an impossibility, though I think it's the best solution because it might allow us to select locales for various client and web l10n efforts.

Comment 5

8 years ago
There's more choices:

bugzilla supports default-CC, which we can employ to notify the localizer, or just a subgroup of larger teams, and people can un-CC themselves if they're not keen on too much bug spam.

To me, the structure of products and components should help us in queries. I see two use-cases:

- What's open in my localization?
- How are which locales doing for project X?

IMHO, we should optimize on the first, as we can use tricky queries to catch our use cases.

There are communities out there that would like to get their own bug components for their local community, too.

Which aligns me with stas' point 4, maybe it's time to rethink if "Mozilla Localizations" is a top-level thing like "Client Software", then we could have "products" per locale, and a "General" component, with optionally more, for www.mozilla.com, Firefox, Thunderbird, or custom ones. We could bootstrap the "General" component with a default-CC of the new owners for new locales. Would make our lives simpler there, too.

That would help Stephen's case, too, one tracking bug in www.mozilla.com, and just dependency noise. Which is probably the right thing, if he wants to know how www.mozilla.com is doing in general. If that's not, I suggest Stephen gets himself on default-CC for www.mozilla.com and then has richer options to ignore particular bugs.
(In reply to comment #3)
> 4. Create a new classification for localization ("Mozilla Localizations") and
> either do (products: Products, components: Locales) or (products: Locales,
> components: Products). I'm not sure yet which one would be easier and for whom.
> The biggest disadvantage of this solution is that it requires the most work and
> is a really big change in the bugzilla hierarchy.

I like this concept most. It sounds to me like the right solution for the longer run, and I'd prefer to do such switches once and for all.
What worries me here are two things:

1) Having to create one row/column of a grid each time we add locale/product. Say, we add Fennec and we have to add a component to each locale. Or we have to add all locales to product Fennec. We can automate it to some degree but it sounds like something that requires maintenance.

2) Further community chunking. By default we'll have people from Fennec ab-CD localization separated from Firefox ab-CD localization, and websites ab-CD localization. Each group is separate and unless they opt-in using Bugzilla watching feature, they don't see what's up with other areas. Same goes with cross-locale per-product community.

I'm wondering if we could tune Bugzilla default-CC's a little bit to preserve the in-bug communication around "Fennec localization", and "ab-CD activities" or is it a trade-off for improving signal/noise ratio.

Comment 7

8 years ago
I just opened a thread in .governance to discuss this in a more appropriate forum than this bug.

I personally don't think we really need separate components per locale by default, it's really just something I'd do for bigger teams. I'm totally fine to have our bug filing templates just file into "General" and leave the triage of those bugs to the teams that like to use more than one component.
(In reply to comment #4)
> (In reply to comment #3)
> > 1. Create a 'localization' component under Websites. It will not be divided
> > further into separate locales.
> 
> Perhaps I am not understanding, but why could we not divide into separate
> locales after creating the component localization?  What about a present
> example like the Fennec project where only a subset of locales are
> participating.  Won't we want the ability to select individual locales for
> various projects?

I think we'd like to be able to divide into separate locales (e.g. for Fennec, as you mention) and that's precisely the shortcoming of the approach no. 1 on my list. The 'localization' component would have a technical limitation on Bugzilla's side. Components cannot be further divided. The hierarchy can consist of a maximum of 3 levels, i.e. classification ("Client software"), product ("Mozilla Localizations"), component ("pl / Polish"). Another current example: ("Other","Websites","www.mozilla.com").
(Reporter)

Comment 9

8 years ago
Have you guys decided on something?  I can create a filter in the meantime...

Comment 10

8 years ago
No, we haven't yet decided what to do for real. I'd like to test-drive our proposal on landfill, but I lack the time to do that with all the releases running through just now.
Please take action before Stephen explodes.
(Reporter)

Comment 12

7 years ago
Alex pointed me to http://groups.google.com/group/mozilla.dev.l10n.web/browse_thread/thread/4467342ea38e97c9/4487ebf73ab77275; how soon before that's implemented?

Comment 13

7 years ago
I'm picking up some technical tests for bug 556236 again right now. Marking that as a blocker for this one, I guess we'll resolve this as a dupe in the end.
Depends on: 556236

Updated

7 years ago
Blocks: 627704
Assignee: mozillamarcia.knous → nobody
(Assignee)

Updated

6 years ago
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
closing bug due to inactivity.  please re-open this bug if still relevant.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
mozilla.com is now part of www.mozilla.org product and an L10N component was created recently for www.mozilla.org, therefore marking fixed
Resolution: WONTFIX → FIXED
You need to log in before you can comment on or make changes to this bug.