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
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
>
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.