Dealing with localizations without active teams
Axel Hecht
I wanted to open a discussion on how we deal with localizations that
don't have an active team. The initial post goes to both .l10n and
.planning, follow-up/reply-to set to .planning.
To start the discussion, we do have an example at hand, but it's not
really that important who what why. It's not too surprising that we're
facing the problem given the number of localization teams we have that
depend on one or two people. We've been lucky enough so far to get
enough new volunteers in, but that's not going to stay that way forever.
This is really nobody's fault, we just need to figure out how to deal
with it.
I'll phrase the discussion around Firefox, but it wouldn't hurt if the
plan is applicable to other apps as well.
Underlying principles in my thinking would be:
* Users first.
** We want our users to use a secure Firefox
** We want our users to use Firefox in the language of their choice
** We don't want surprises
* Community second
** we don't want to exclude existing contributors nor new ones
** if possible, keep the owner in charge or at least in the loop
** rely on existing peers to take ownership if owner can't be reached
** go with "acting owners" in case of the completely missing team (or
sole localizer)
** no surprises, again
I'll start with what we're doing on the community side already:
- mails and bugmails trying to figure out the status
- if there are volunteers on our radar, try to bring them in contact
with the existing team
- try to find alternative email addresses in case of no response,
possibly phone contact even
- blog/twitter/facebook searching for new volunteers
- investigate other open source projects for volunteers
We might add
- ask for volunteers as a startpage snippet
The overall idea is to get new people to work on top of the existing
localization such that we get a stronger team if the original members
come back, and hopefully not a weaker team if they don't.
Over to what we do for our users, i.e., what do we do with existing
users, and with new users for that language.
- I don't think we should get new users onto a piece of software that is
no longer maintained. (Nightly testers excluded, those might get
volunteers.)
For existing users, we want to make sure that we keep them on a build
that knows that they prefer a particular localization. That way, if we
resurrect the localization team and the localization is ready for
end-users again, we should update those users from whatever they have
been using back to their now-supported localized build.
While we're not having a supported localization, I see two alternatives:
- pad the existing localization with English strings and keep users on a
partially translated build.
- convert them to a fully English build, with a tweaked locale setting
to be able to update them back to a localized build.
Whenever we do either, and the switch back, the whatsnew page should
clearly detail on why something happened, and what. I'd be fine for that
messaging to be in English, and if applicable, have a link to some
google machine translation, for example.
My personal take is that we should make the call on whether to fully
english-ify or partially translate on a case by case basis. The
difference between 3.0 and 3.5 for example posed a different problem
than 3.5 to 3.6 will. Some locales might start with a good coverage
making the en-US padding less evil, or the other way around.
What do other people think?
Axel
Дамјан Георгиевски
> english-ify or partially translate on a case by case basis. The
> difference between 3.0 and 3.5 for example posed a different problem
> than 3.5 to 3.6 will. Some locales might start with a good coverage
> making the en-US padding less evil, or the other way around.
A partially translated application could actually be a very effective
recruit technique.
I personally, would prefer that for the .mk locale - instead of a non-
existent locale - perhaps a release like that should be tagged somehow,
but still available from http://www.mozilla.com/en-US/firefox/all.html
ps.
when the Macedonian Firefox 3.5 didn't ship people were inclined to
think there is some conspiracy against it.
--
дамјан ( http://softver.org.mk/damjan/ )
A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?
Juan Becerra
We should identify all the one/two-person localization teams and try to
help them as much as possible in getting more people involved,
especially those whom we can contact directly when there are deadlines.
What if a localizer disappears, but his localization is in the the same
language as an existing one? We could then afford to not ship that
specific locale, and point users to the existing language localization
instead?
What if only a very small amount of strings change or are added between
versions and we don't have a point of contact? Could we not try to
translate the strings ourselves, especially if we have a way to allow
almost anyone to translate and submit the changes?
If a localization is mostly complete, such as most menus and preferences
and security and privacy dialogs, can we release as a beta and use it as
a way to attract a new batch of localizers who might be interested in
completing the work? Would there be a basic set of strings that once
translated we could consider sufficient in order to do this?
We should try to prevent having a localization effort depend on one
person by helping them get more people involved.
juanb
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
Pavel Cvrcek (Mozilla.cz)
> We should try to prevent having a localization effort depend on one
> person by helping them get more people involved.
Easy to say, hard to do. Firefox isn't a hype like was few year ago and
it's harder to get new people for Mozilla project. Many users visit
Mozilla websites but I'm not sure if there is enough info how to get
involved in local communities.
Short look (for "cs" locale):
==============================
http://www.mozilla-europe.org/cs/
- no visible info how to get involved
http://cs.www.mozilla.com/cs/
http://support.mozilla.com/cs/kb/How+to+contribute
- link to community site
http://www.mozilla.com/en-US/about/get-involved.html
http://www.mozilla.org/contribute/
- nothing about local communities and how to get involved
But I'm not sure how these pages are effective for getting new people
for project. But some "get involved" page on Mozilla Europe website
should help us.
Another thing is how to make local communities easier to live. But
that's another story.
--
Pavel Cvrček <pcv...@mozilla.cz>
http://www.mozilla.cz/
Gervase Markham
> While we're not having a supported localization, I see two alternatives:
> - pad the existing localization with English strings and keep users on a
> partially translated build.
This sounds like the best plan.
How many strings have changed from 3.5 -> 3.6? And how important are they?
> Whenever we do either, and the switch back, the whatsnew page should
> clearly detail on why something happened, and what. I'd be fine for that
> messaging to be in English, and if applicable, have a link to some
> google machine translation, for example.
Surely we can do better than that? I know we don't pay for translations
in general, but surely it would be better to pay for a translation of
these three sentences than rely on machine translation.
Gerv
Axel Hecht
Localization is not a one time thing, it's software engineering like all
other code.
I really don't like the idea of shipping software that's not maintained,
and that goes independently of how many strings that has padded in in
English. For software that we endorse on our pages as "Firefox", people
should have a chance to file bugs and have someone pay attention to them.
If we can take some amount of money to help a community around a
localization to come back to life, or create a new one, that's
different. Taking money to just get a few strings has proven itself to
be a bad investment in the past though. (Even if it wasn't our money at
the time.)
Axel
Gervase Markham
> If we can take some amount of money to help a community around a
> localization to come back to life, or create a new one, that's
> different. Taking money to just get a few strings has proven itself to
> be a bad investment in the past though. (Even if it wasn't our money at
> the time.)
Yeah, but paying for people to translate "Do you want Firefox to save
this password?" is very different from paying people to translate "Hey,
we don't have any translators, which is why some of this product is in
English. Can you help us?"
Then again, we could leave that text in English, because if they can't
read it, they are probably not going to be able to help :-))
Gerv
Seth Bindernagel
Juan Becerra wrote:
> If a localization is mostly complete, such as most menus and
> preferences and security and privacy dialogs, can we release as a beta
> and use it as a way to attract a new batch of localizers who might be
> interested in completing the work? Would there be a basic set of
> strings that once translated we could consider sufficient in order to
> do this?
Hey Juan, thanks for the thoughtful feedback and ideas.
To this point above, historically, we've tried to ship only
fully-translated localizations, keeping the newest ones in beta to make
sure they have enough time for end-users to adopt and provide feedback
if the translations need further work. I am not sure we'll ever ship
something that is partially translated, in hope to entice others to
contribute. We've always pushed an all-or-nothing strategy to make sure
our end-users are getting fully-localized Firefox for use, even if it is
in beta.
I am not sure if we are going to change this policy, but one important
thing to note is Axel's "l10n-merge" code that we have as a resource.
Though we would never use a combination of English and non-English
strings as a shippable product, we do have the ability to produce
"testable" builds for new localizers. So, in a way, your suggestion
above is already in practice.
Axel Hecht
To add here:
I see beta releases as the phase in our release cycle where we try to
ramp down the remaining blockers as quickly as possible, and expose the
work to a wider not-so-technical audience to get even the odd edge cases.
To get attention of developers, we do nightly builds. They're hard to
find, and I thought there was mention of a project to fix that at some
point, but still.
The nightly builds do come with padded en-US strings, fwiw.
Axel