AMOv3 dynamic localization plan
Wil Clouser
AMOv3. In my mind, we've got 2 main sections: System translations and
Add-ons translations.
The system translations are things like category names and descriptions,
which, up till now, I've put into the database manually as localizers
send them to me (thanks for putting up with our system so far! :)).
The add-ons translations already have a localizing interface, but it's
only accessible to the owner of the add-on.
So, goals we need to address:
1) Determine a way to label an account as a "localizer" and associate
them only with locales they know.
2) Provide a way for a localizer to add/edit System translations
3) (maybe) Provide a way for a localizer to add/edit add-on translations
I said "maybe" on that last one, and I'd like to expand on it - do we
want to get into the business of introducing localizers and add-on authors?
I think it's unreasonable to expect add-on authors to be able to
trackdown localizers for their add-on, and I think it's unfair to ask a
localizer to deal with the flood of mail they would get once their
address got discovered by add-on authors.
And so, and this is brainstorming at it's finest (worst?), we could add
a flag to the add-ons that said "Localizations welcome." When the
add-on author added the flag, we could show them a short blurb about an
ideal add-on (eg. the description should not be version dependent and
shouldn't change frequently, etc.). I assume we'd also need to add some
sort of disclaimer that a localizer could potentially misrepresent the
add-on and cause a hardship to the author.
Once the flag was in place, we could provide an interface for
translations to localizer accounts. The system could even detect when
it was displaying content in a language other than what was requested,
and could provide a link that said "Translate This" next to the content...
Anyway, links are a minor concern at this point - I'm interested in the
overall plan at this point:
Is having accounts marked as "localizers" a solid idea? Will localizers
be willing to login to Yet Another System to translate strings?
Is the process reasonable? (login, go to "some interface", translate
string, string is live)
Should we have any kind of review before a translation is published?
Does it matter if the translation is for System or Add-on content?
Should there be a way for the public to "flag" a translation as needing
review?
I'm happy to entertain more questions and ideas. :)
Thanks,
Wil Clouser
Francesco Lodolo
> 3) (maybe) Provide a way for a localizer to add/edit add-on translations
I and other people started some years ago (2004) a project called
eXtenZilla (extenzilla.org): our goal was (is) to provide the best
italian localization for extensions and give support through a forum.
Our localization process is quite rigid:
* localization is always checked by a QA team before approval (a
localizer can't check his own localization)
* localization is tested inside the application to check if strings
are fully displayed, window sizes, etc.
* localization must be correct (obviously)
* localization must be coherent with the browser localization (not
so obvious but not less important)
How can AMO check the quality of a localization and assure this type of
QA? The author obviously is unable to do this kind of control.
Another point: localization should be done before the publication, not
after (even if this could be reasonable for the descriptions on AMO).
After eXtenZilla a new project has born: BabelZilla (babelzilla.org,
2005), an international forum where localizers and authors can meet and
find/offer help about translations.
On BabelZilla there's also a very good translation system: you can
localize extensions using a web application and you can't ignore tech
stuff like utf, enconding, entities, etc.
Francesco.
Jesper Kristensen
* It does not make sense to have a description localization without having an
addon localization.
* It should require as little extra work as possible to localize the
description of the addon, when you are already localizing the addon itself
(is there anything other than the description, that should be localized?).
In my mind, the best solution would be to make localization of the
description part of the localization of the addon itself. I see two options:
1: Make the addon description (and other localized data, if any) part of the
addon. AMO should read the xpi and extract relevant localized data from it at
upload time.
2: Integrate with the localization framework. I have heard (not used it
myself), that babelzilla is used for almost all addon l10n. It may be
possible to add addon meta data to the l10n process there, and AMO could pull
it automaticly from their web site.
I know that neither of my suggestions are trivial to implement for the AMO
development team, but I think it is essensial not to require yet another
login for localizers or yet another thing to keep track of for addon
developers. I would be happy to help with the development.
--
Jesper
Denmark
Archaeopteryx
> So, goals we need to address:
> 2) Provide a way for a localizer to add/edit System translations
>
> 3) (maybe) Provide a way for a localizer to add/edit add-on translations
>
> I said "maybe" on that last one, and I'd like to expand on it - do we
> want to get into the business of introducing localizers and add-on
authors?
Talking to the leading translation group for Mozilla Add-ons,
http://www.babelzilla.org is highly recommended.
> I think it's unreasonable to expect add-on authors to be able to
> trackdown localizers for their add-on, and I think it's unfair to ask a
> localizer to deal with the flood of mail they would get once their
> address got discovered by add-on authors.
I have another experience. Some add-on authors only want to provide
their software in one language (even if it is not their native one)
because they don't want to manage or care about localization.
> Is having accounts marked as "localizers" a solid idea? Will localizers
> be willing to login to Yet Another System to translate strings?
Depends on the system. I could live with doing this and using the Cookie
Swap extension. Or the add-ons are translated at another site with two
parts: One with the entity list where the user can type in the
translation, the translated string(s) get highlighted like in scrapbook
edit mode and changes are show after pressing a button or after changing
the focus.
> Is the process reasonable? (login, go to "some interface", translate
> string, string is live)
>
> Should we have any kind of review before a translation is published?
Yes, knowing Babelzilla shows that a review is highly recommended. Some
people produce terrible "translation": Not all translated, user other
words as used on other pages/in Firefox, typos, not
descriptive/understandable. Maybe (<< forget this word) someone out of a
group of experienced translators should give his or her OK for making it
live.
> Should there be a way for the public to "flag" a translation as needing
> review?
Definitely yes.
Francesco Lodolo
> I think that AMO should not address this point and I'll try to explain
> why.
of localizing extensions trough AMO:
* this is going to overlap with existing local or international
projects (like extenzilla, babelzilla and maybe others); perhaps
this is not so important for AMO but it's the main problem for me ;-)
* AMO can't assure a QA process
* AMO can't evaluate the quality of the localization (and even the
authority of the localizer)
Francesco.
Cédric
> The system translations are things like category names and descriptions,
> which, up till now, I've put into the database manually as localizers
> send them to me (thanks for putting up with our system so far! :)).
>
> The add-ons translations already have a localizing interface, but it's
> only accessible to the owner of the add-on.
Oh : you're talking about the translation of the Add-ons and not the
descriptions!
Well, I guess the first step would be to translate first the
descriptions, and to have a way to track down the progress and the
changes occurred to descriptions already translated.
> So, goals we need to address:
>
> 1) Determine a way to label an account as a "localizer" and associate
> them only with locales they know.
Yes, why not. But how will you check that the people applying for a
locale is serious? The same vouching system as for CVS access? The
vouchers might be the owners and peers from the products or people who
already localize Mozilla-europe/ mozilla.com pages?
>
> 2) Provide a way for a localizer to add/edit System translations
Yes
> 3) (maybe) Provide a way for a localizer to add/edit add-on translations
>
> I said "maybe" on that last one, and I'd like to expand on it - do we
> want to get into the business of introducing localizers and add-on authors?
Localizers who want to be a resource for Add-on authors might be
listed somewhere, then up to the authors to contact them.
Also, we might want to have the possibility to translate the add-ons
even without contacting the authors (much less e-mails ;) )
Maybe a simple interface a la Bugzilla with simple requests like :
- which add-on descriptions for a locale are not translated
- which ones have been updated and are awaiting for localization
updates
- which add-ons are not translated for a locale
- which add-ons have been updated
> I think it's unreasonable to expect add-on authors to be able to
> trackdown localizers for their add-on, and I think it's unfair to ask a
> localizer to deal with the flood of mail they would get once their
> address got discovered by add-on authors.
Agreed
> And so, and this is brainstorming at it's finest (worst?), we could add
> a flag to the add-ons that said "Localizations welcome." When the
> add-on author added the flag, we could show them a short blurb about an
> ideal add-on (eg. the description should not be version dependent and
> shouldn't change frequently, etc.).
Agreed, but I guess the new release of a version wants to hightlight
the important changes
> I assume we'd also need to add some
> sort of disclaimer that a localizer could potentially misrepresent the
> add-on and cause a hardship to the author.
>
> Once the flag was in place, we could provide an interface for
> translations to localizer accounts. The system could even detect when
> it was displaying content in a language other than what was requested,
> and could provide a link that said "Translate This" next to the content...
Due to the high number of add-ons, it would be difficult to a
localizer of even a team of localizers to find what are not localized
that way.
> Anyway, links are a minor concern at this point - I'm interested in the
> overall plan at this point:
>
> Is having accounts marked as "localizers" a solid idea? Will localizers
> be willing to login to Yet Another System to translate strings?
>
> Is the process reasonable? (login, go to "some interface", translate
> string, string is live)
It's dangerous. The site could be broken. We would need a stage-server
to look if all is good before publishing
> Should we have any kind of review before a translation is published?
Yes, up to the team to validate; so they should be owners and peers
for a locale I believe.
> Does it matter if the translation is for System or Add-on content?
I think that the system is more important than the add-on content :
system's menus won't be changed frequenly I guess, and they are shown
on every pages of the site, so system's strings localizations must be
of a good quality.
> Should there be a way for the public to "flag" a translation as needing
> review?
>
> I'm happy to entertain more questions and ideas. :)
I think we could inform the visitor if an add-on is localized in its
language (according to the user agent string of its browser)
>
> Wil Clouser
Cédric Corazza
Nukeador
- System translations (The translation team would do this)
- Popular addons descriptions (if the addon is localized, mail the
author to get the localized description from its localizer or let the
localizer team to do that. I think every team could translate the popular
addons descriptions if the author or its localizer don't do that.)
- The rest of the descriptions (the author should get a translation
from its localizer or call for help. Not all teams could translate hundreds
of non popular addons.)
- Non popular addons already localized in our language (The team
decide which ones marked as "The author called for help" are translated
first)
- Non popular addons not localized in our language (Could these
be translated by volunteers if the author couldn't?)
- Extension localization (I think than would be a good idea with a
babelzilla-like system, maybe a collaboration?)
To sum up with the descriptions:
Extension (if the author is unable to do it)
Popular -> Translated by the local team
Non popular
Translated extension? -> Local team (volunteers help?)
Non translated extension? -> Volunteers
--
Nukeador
Spanish Team
Pavel Franc
speaking for our Czech Mozilla cmmunity.
> So, goals we need to address:
> 1) Determine a way to label an account as a "localizer" and associate
> them only with locales they know.
I would also strongly suggest to be able to label account as a "l10n
leader" for people responsible for the locale. These l10n leaders would
be able to grant someone the "localizer" status, translate system
strings, flag add-on as reviewed ...
> 2) Provide a way for a localizer to add/edit System translations
leaders. To be the system simple there would not have been a review of
System translations. So it should not be open to every localizer.
> 3) (maybe) Provide a way for a localizer to add/edit add-on translations
description if they want to (Our Czech community certainly want to
translate summary/description for all addons with Czech localization).
And there should be a way for authors to say - hey, it would be a really
nice if you translate my summary/description.
In our community, usually one localizer cares somehow about some set of
add-ons. Therefore, it would be nice if a localizer could flag an add-on
as My Add-on.
> The system could even detect when it was displaying content in a
> language other than what was requested, and could provide a link that
> said "Translate This" next to the content...
For localizers and l10n leaders I would suggest to introduce a l10n
Control Panel that would list All add-ons/Untranslated
add-ons/Translation wanted/My add-ons,/Needs review...
> Should we have any kind of review before a translation is published?
> Does it matter if the translation is for System or Add-on content?
Yes. As I wrote above, the System content should be accessible only for
l10n leaders with no review. The Add-on content should be accessible to
any localizer in the particular language with a review from l10n leaders.
> Should there be a way for the public to "flag" a translation as
> needing review?
No, just localizers should be involved.
Best,
Pavel Franc
--
CZilla - www.czilla.cz
Mozilla Europe - www.mozilla-europe.org
OSS Alliance - www.oss.cz
Marcelo Poli
> * It does not make sense to have a description localization without having an addon localization.
"Firefox Showcase" is an example. If you don't need to personalize the
extension, it works without any language text.
BTW, Showcase is translated to many languages, but it was one extension
that I use and it's a good example.
goo...@gmail.com
>
> Localizers who want to be a resource for Add-on authors might be
> listed somewhere, then up to the authors to contact them.
> Also, we might want to have the possibility to translate the add-ons
> even without contacting the authors (much less e-mails ;) )
> Maybe a simple interface a la Bugzilla with simple requests like :
> - which add-on descriptions for a locale are not translated
> - which ones have been updated and are awaiting for localization
> updates
> - which add-ons are not translated for a locale
> - which add-ons have been updated
>
>
> > Is having accounts marked as "localizers" a solid idea? Will localizers
> > be willing to login to Yet Another System to translate strings?
>
> > Is the process reasonable? (login, go to "some interface", translate
> > string, string is live)
>
> It's dangerous. The site could be broken. We would need a stage-server
> to look if all is good before publishing
>
> > Should we have any kind of review before a translation is published?
>
> Yes, up to the team to validate; so they should be owners and peers
> for a locale I believe.
>
> > Does it matter if the translation is for System or Add-on content?
>
> I think that the system is more important than the add-on content :
> system's menus won't be changed frequenly I guess, and they are shown
> on every pages of the site, so system's strings localizations must be
> of a good quality.
>
I am slightly surprised that most of the features you are wishing are
already available on http://www.babelzilla.org (which is far from
perfection obviously but provides smart tools and a well-known meeting-
point for devs and translators); and you seem not to be aware. Please
browse one minute on babelzilla.
Of course we are open to collaboration :)
- Goofy
BabelZilla Team
Jesper Kristensen
* Addons that is being localized
* Addons where authors won't put localizations in the official release, but
still allow some 3rd party l10n. (Not sure what fits into here. Language
packs?) Example: ChatZilla.
* Addons that don't need localization (Extensions with no textual UI, themes)
I discovered that my proposal earlier only takes the first category into account.
Goofy
text included in the extension (as already suggested by someone here)
is interesting.
- it could be a simple descriptive_text.properties file in the en-US
- it would be recognized by the Web Translation System on BabelZilla,
so translators will just have another part to translate if needed (of
course for the moment not all languages are required on AMO as far as
I can see)
- the text (as the rest of the extension translation) could be
reviewed and proofread on BZ (major language forums on BZ manage to do
that, but it is true that for some languages the language team is so
reduced that there cannot be real control unfortunately)
- it would be only the developer's responsibility to copy/paste these
descriptive texts in the appropriate AMO fields, thus it will avoid
the problem of accesss to the editable fields on amo (no special login
required for translators, no problem of reviewing text once translated
directly by someone online), developers only will access these
descriptive fields with their usual login
(tell me what you think)
- Goofy
BabelZilla Team
Goofy
I have been discussing that question on BabelZilla with our Tech Admin
and reached this kind of conclusion :
- the idea mentioned above (having the descriptive included in the
extension en-US locale just as another file) is valid and need no
further work on our site, the work will only be on the developer's
side
- if it is too much a pain for the developer to include one extra file
which will probably be removed in the final version of the extension,
there is no problem for us to create a link to a new form with 3
fields (summary, description, privacy policy) that will be filled
(distincltly for the submission of the extension) by the developer
then get various translations (similar to hat you have on amo3
preview)
We are waiting for your suggestions and observations
Goofy
BZ Team
Wil Clouser
Adding form fields sounds like the fastest (and easiest for the authors)
way to do this. If it's relatively easy for your team, I like the idea.
Currently, the localizable fields for an add-on are:
Name
Homepage
Summary
Description
EULA
Privacy Policy
Wil
Wil Clouser
>
> I am slightly surprised that most of the features you are wishing are
> already available on http://www.babelzilla.org (which is far from
> perfection obviously but provides smart tools and a well-known meeting-
> point for devs and translators); and you seem not to be aware. Please
> browse one minute on babelzilla.
> Of course we are open to collaboration :)
>
>
> - Goofy
> BabelZilla Team
>
>
Hey folks,
Thanks for everyone's great ideas, and apologies for my absence from
this thread. I've read through everything here, and several ideas have
been implemented. For those localizers involved with AMO already, this
will be review, but I'd like to do a quick summary of where we stand today:
- There is a document for how to localize remora into a new language:
http://wiki.mozilla.org/Update:Localizers
- SVN access is granted to those who have access to mozilla.com SVN and
are on an l10n team so localizers can update thier own files.
- AMO has a concept of permissions for localizers. If you are a member
of a localization group, when you login, you'll see a link on the left
hand menu named "Localizer Tools"
- The Localizer Tools:
- Lets you see which static pages are localized
- Lets you see which strings are not localized in your locale's
gettext file
- Lets you see and modify dynamic strings on the site
The permissions for the localizer tools are pretty simple - if you have
access, you can modify. There is no review. Currently, the only people
with permission are those with SVN access. I expect this particular
tool to stay pretty simple in that regard - this tool only deals with
interface localization (nothing to do with add-ons).
Overall, I think we've got a pretty good system for translating the
interface. Most of the major issues have been worked out, and I haven't
heard any major complaints recently.
Which brings us to localizing the dynmamic content of add-ons. I think
collaborating with an existing site (like babelzilla.org or
extenzilla.org) is a fantastic idea, and would be the fastest way to
help add-on authors at this point.
I spoke with several other people today, and our plan is to create a
page on the Mozilla Developer Center with information on localizing
add-ons. From that page, we can have links to relevant sites that offer
translation assistance.
I think this is a good first step towards developing a long term plan.
Thoughts?
Wil Clouser
(The amo-l10n@ list got dropped somewhere along the lines, so I'm
re-adding them here. Sorry for the abrupt drop in the conversation -
you're welcome to catch up on the newsgroup archives)
Goofy
anywhere in the dev list jungle, please tell me):
I noticed there are currently 12 (cs/da/de/en-US/es-ES/fr/it/ja/ko/ro/
ru/sk/sq) languages available for potential translation, which is very
promising. What is the general policy to choose them? Is there any
chance other languages may be added? For example, a Dutch major
contributor on BabelZilla would like to contribute, and I suppose that
a good number of other folks around the world will request one day or
another.
Let us know, TIA
- Goofy
BabelZilla Team
Wil Clouser
Currently, all the localizers are already active members of a Mozilla
language team. If your contributor isn't, I'd suggest they get in touch
with the Dutch localization team so we can coordinate efforts.
Wil
> _______________________________________________
> dev-l10n-web mailing list
> dev-l1...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n-web
Wil Clouser
> I spoke with several other people today, and our plan is to create a
> page on the Mozilla Developer Center with information on localizing
> add-ons. From that page, we can have links to relevant sites that offer
> translation assistance.
Here is the document I mentioned earlier today:
http://developer.mozilla.org/en/docs/Localizing_extension_metadata_on_addons.mozilla.org
To extenzilla and babelzilla (and any others I don't know about): If
you support translating the additional metadata fields on your site,
please add a link to your site and a brief description of how you can
help add-on authors.
Once the page gets some more data on it, we can look at linking to it
and promoting add-on translation.
Thanks,
Wil
Axel Hecht
Thanks for setting this up, and for Goofy to jump right at it. I did
some small nits on localization vs translation vs locale, to both Wil's
and Goofy's content.
Axel
Mad Maks
For example, a Dutch major
> contributor on BabelZilla would like to contribute,
Let he contact me and i will list him as a member of our team for
translating AMO and request access for him.
greetings
MM