Closed Bug 245948 Opened 17 years ago Closed 14 years ago

localize AMO

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: steffen.wilberg, Unassigned)

References

()

Details

(Keywords: helpwanted, intl, l12y)

Attachments

(2 obsolete files)

Mozilla Update should be available in more than one language.
Mozilla Europe should watch this. At least.
Is this application localizable? If so, is there any doc we can read where we
can evaluate to amount of work needed to localize it?

Mozilla Europe should probably have is word to say, as we have already people
working on our web site localization in FR, DE and ES, with more languages coming.
The site wasn't designed with localization in mind.. It's mostly print()'d text
strings and other localizer unfriendly methods. So there's no documentation on
localizing this available.

This is a by aviary-1.0 goal, hopefully. To get the site where it can handle
being localized and to find people who can translate the text. 

Keeping in mind of course, it's database driven, and most extensions are in
english, with descriptions and stuff being entered by author.. so at most it'd
only be partially localized. Unless the alternate language pages only show
extensions that are in the same language.
we should also include what languages the extensions are in:
http://www.geocities.com/stolenclover/intl/
*** Bug 249775 has been marked as a duplicate of this bug. ***
Assignee: nobody → psychoticwolf
(In reply to comment #3)
> Keeping in mind of course, it's database driven, and most extensions are in
> english, with descriptions and stuff being entered by author.. so at most it'd
> only be partially localized. Unless the alternate language pages only show
> extensions that are in the same language.

It would be nice if the localizers were also able to translate the descriptions,
and then automatically get notifications if the description was updated.

I'm not sure how it is now, but you could also possibly add a checkbox to the
Extension Update form like "Invalidate localized descriptions" that would let
the author invalidate current translations if he feels the new description is
too drastic to wait for localized updates.
Severity: normal → enhancement
Whiteboard: after-aviary1.0PR
This doesn't have to be localization of extension descriptions, but the
framework of the site itself.
Depends on: 255444
No longer depends on: 255444
Of course that's the first step. Later on we'll also need localisable
descriptions. Everything else would be quite inkonsitent and of no help for non
english speaking users
Wolf, as this has the helpwanted keyword, could you lay out what one had to do,
and how to get to it? Like, where is the code, what needs to be done, which tasks
are there to synchronize with.
(In reply to comment #6)
> It would be nice if the localizers were also able to translate the descriptions,
> and then automatically get notifications if the description was updated.

I disagree, for the following reasons:

1) Extensions that ship with multiple locales

These extensions have their own localizers, and they should have control about
how descriptions are translated. Therefore, I think each extension should ship
its localized descriptions (plus extension name and author) in install.rdf, as
proposed in bug 257155.


2) Single-locale extensions

To me, it does not make sense to have a localized description of an extension
that is not available in my language and has no documentation in my language.
And if I was informed of that fact and I decide to use a foreign-language
extension anyway, I had certainly also been able to understand a
foreign-language extension description...


However, I agree that getting rid of "localizer unfriendly methods" and removing
hard-coded strings from the site framework is a priority. Extension texts are a
separate issue, though not neccessarily technically dependent on the localizable
site.
Whiteboard: after-aviary1.0PR
Biggest thing that needs to be done here, is the site strings need to be made
localizeable.

The extension install.rdf data we import, would be very difficult to localize
and maintain, as it can change every day, if the author wanted to. :-)

I'm not going to get to this before 1.0.. Others have expressed interest in
taking this. --> nobody.
Assignee: psychoticwolf → nobody
*** Bug 264046 has been marked as a duplicate of this bug. ***
I won't take this bug, because I'm afraid it's bit too big for me, but I'm happy
to help. Just mail me... 
Wolf, please state what is needed to make the site localizable. Especially: is
there some way to browse the source code? Either by LXR or via anonymous CVS?

I would coordinate the efforts if I could estimate the amount of work to be done.

Greetings . . . Martin
Keywords: l12y
Martin alreade found it and posted it at firefox-browser.de:
http://lxr.mozilla.org/mozilla/source/webtools/update/

I had a quick look at the code and I'm afraid we need to recode it. I think it's
ok for the moment, but localisation es well as extension and maintance are a bit
difficult. 
We'll be using gettext() 

http://us2.php.net/gettext

http://us2.php.net/manual/en/function.gettext.php

Doesn't look that bad.
I skipped the News items, since they're potentially dynamic.
Is it really a good idea to do this:
----
echo _("Extensions are small add-ons that add new functionality. They can add
anything from a toolbar button to a completely new feature.")
----

The german translation file would then (structurally) look like:
----
Extensions are small add-ons that add new functionality. They can add anything
from a toolbar button to a completely new feature.=Erweiterungen sind kleine
Add-Ons, die neue Funktionalitäten bereit stellen - von Toolbar-Buttons bis hin
zu komplett neuen Funktionen.
----
(notice the = in the middle)

I understand that it's convenient to pass the full english text to gettext, so
it is displayed if no translation is available. However, it has a big drawback:
If even a single character is changed in the english texts that are hard-coded
into the PHP files, *all* translations would have to be updated, because
otherwise the texts would no longer be found!

I suggest using IDs as in Mozilla's localization (DTD, properties files), like this:
----
echo _("ExtensionExplanation")
----

English Translation:
----
ExtensionExplanation=Extensions are small add-ons that add new functionality.
They can add anything from a toolbar button to a completely new feature.
----

German Translation:
----
ExtensionExplanation=Erweiterungen sind kleine Add-Ons, die neue
Funktionalitäten bereit stellen - von Toolbar-Buttons bis hin zu komplett neuen
Funktionen.
----
Re comment #18: the disadvantage of this approach is that it makes it harder to
connect the translation with the german text. There are standard gettext tools
that will manage the updates.
Bulk Moving Web Site bugs to new component.
(Filter: massumowebsitespam)
Component: Update → Web Site
Product: mozilla.org → Update
Version: other → unspecified
Depends on: 258478
Attached patch Localization of front page (obsolete) — Splinter Review
Assignee: nobody → Bugzilla-alanjstrBugs
Attachment #166893 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #169508 - Flags: first-review?(psychoticwolf)
(In reply to comment #21)
> Created an attachment (id=169508) [edit]
> Localization of front page
> 

On IRC I asked how extension's descriptions are displayed. With the content of
install.rdf ? With a text submited by the author ?

If you use install.rdf, this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=257155 is annoying...
We don't have the ability to localize descriptions yet.  You can't even do them
in the install.rdf yet.  It would help if that happened first.
Shall we do something with that now, is anything planned?
Take a look at bug 257155
No, I meant your patch. You just posted it without any instruction or
description. Shall we start translating anything, is anything planned about it,
any timeline etc.?
Well, I wouldn't call it official until it gets checked in.   It should give you
a good place to start, though.  I don't want to do too many pages because
they'll bitrot too fast.
Target Milestone: --- → 1.1
Bad news:
I'm going to have to take a step back in order to make this work well with bug
272806 (templating).  

http://sourceforge.net/projects/smarty-gettext/ looks like it will be what I need.

The strings will be the same, just moved around.
Attachment #169508 - Flags: first-review?(psychoticwolf)
Depends on: 272806
Attachment #169508 - Attachment is obsolete: true
Can someone please look at the attachments on bug 272806 and tell me if I'm
doing this right?  
Part of the smarty gettext package contains a helpful tool.  If it doesn't do
what you need, you're looking for everything between {t} and {/t}.  

tsmarty2c.php - the command line utility
----------------------------------------
This utility will rip the translation strings from the smarty files, and convert
them to gettext calls in C, that can later be used with the standard gettext tools.
Target Milestone: 1.1 → 2.0
Depends on: 285850
Hey localisers, we're making the switch to templates, featuring Smarty!
Forgive me, Alan, if you object to it going back into the default-assignee queue.  Adjusting TM and severity, this might serve as a metabug for localization infrastructure and collecting the localizations themselves.
Assignee: Bugzilla-alanjstrBugs → nobody
Severity: enhancement → major
Status: ASSIGNED → NEW
QA Contact: mozilla.update → web-ui
Target Milestone: 2.0 → Future
Blocks: 340336
Bugspam makes us be-come druggies
Fa-la-la-la-la, la-la-la-la
Get morgamic some more coffee
Fa-la-la-la-la, la-la-la-la

Updating all the bugs which have "Update" or "UMO" in them.
Summary: localize Mozilla Update → localize AMO
Here is an l10n update on addons:

You can see a sample of a translation here (only the front page):

English (en_US):
https://update-staging.mozilla.org/~clouser/v2/public/htdocs/

French (fr_FR):
https://update-staging.mozilla.org/~clouser/v2/public/htdocs/?lang=fr_FR


(The french is all babelfish'd so my apologies ahead of time if I've butchered it.)
  
Currently every string that is shown on the page (including alt and title attributes, etc.) are replaced in the smarty templates by some placeholder text surrounded by a call to a t function.  For example:
  
The original template:
    Featured Extension
  
The new template:
    {t}_index_feature_title{/t}
  
The placeholders are named (roughly), _<page>_<description>_<location>, with <location> being "title" "alt" or similar.  Hopefully it makes sense.
  
Anyway, as the sample shows, there are a few things left to be desired, namely:
  
There are a lot of images-as-text on the pages.  I'm not sure how we want to handle that yet, but I fear it could be the source of some delays (if we have to redo every image in every language).

At this point the next steps are to go through every template and replace the english with the placeholders, and create the .po files for all the languages.  After that, we'll ship the .po's to translators, and it'll all be downhill from there.  

So, this is just an update - there is still quite a bit of work to do.

Let me know if you've got questions/concerns/recommendations. :)

PS - Oh, I've been getting some odd blank pages every few refreshes.  I'm not sure if that's just a quirk due to updating the .po files (I know php caches them pretty well) or if it's going to be a problem.  Once I get more pages translated I'll do some benchmarking.  If you see any strange problems, please let me know. :)
Status: NEW → ASSIGNED
(In reply to comment #33)
> 
> There are a lot of images-as-text on the pages.  I'm not sure how we want to
> handle that yet, but I fear it could be the source of some delays (if we have
> to redo every image in every language).

If all the original images were in SVG format, then those SVGs could be fairly easily (I'd imagine) translated through PO-files. Translated SVGs then could be converted automatically to PNGs. Adding that bit of layer to the graphics creation process would help admin work in the long run.

as a short side note: great work making AMO localizable!
Wil, thanks a lot.

Comments, the french hack seems to have an encoding problem. I'm not exactly sure where it is, though, as I my usual View-Charset twisting doesn't improve the '?'.

Regarding the images, localized images tend to get bigger than the en-US ones, does the site layout depend on those sizes critically?
Wil, from my experience with localizing PHP, the blank pages are indeed only something temporary, caused by some apache/PHP caching or such. I'm often seeing this, I think the first time an apache process serves a page after having changed the .po/.mo, but once it loads it correctly once again after the change, it works without problems for evry further access to the pages.
(In reply to comment #34)
> If all the original images were in SVG format, then those SVGs could be fairly
> easily (I'd imagine) translated through PO-files. Translated SVGs then could be
> converted automatically to PNGs. Adding that bit of layer to the graphics
> creation process would help admin work in the long run.

Interesting idea.  I haven't messed with svg->png conversion, and right off the bat I'm a little nervous about speed.  Definitely something to look at though.

> Comments, the french hack seems to have an encoding problem. I'm not exactly
> sure where it is, though, as I my usual View-Charset twisting doesn't improve
> the '?'.

Yeah, I'm getting the same issue too.  I'll look into it. :)

> Regarding the images, localized images tend to get bigger than the en-US ones,
> does the site layout depend on those sizes critically?

After some quick testing, I'd have to say "yes, very much."  It's looking like we might have to do some major template changes to accommodate this.

> Wil, from my experience with localizing PHP, the blank pages are indeed only
> something temporary, caused by some apache/PHP caching or such.

Great, thanks. :)
(In reply to comment #37)
> (In reply to comment #34)
> > If all the original images were in SVG format, then those SVGs could be fairly
> > easily (I'd imagine) translated through PO-files. Translated SVGs then could be
> > converted automatically to PNGs. Adding that bit of layer to the graphics
> > creation process would help admin work in the long run.
> 
> Interesting idea.  I haven't messed with svg->png conversion, and right off the
> bat I'm a little nervous about speed.  Definitely something to look at though.

That is definitely not something that we would do per-request.  We'd update PNGs when the SVG data changed, via CVS hooks or Makefiles or lazy timestamp checking on the server side.

Really, though, we should be looking to use text instead of images-containing-text pretty much everywhere.  Someone want to make a list of the images that are just or primarily text?

> After some quick testing, I'd have to say "yes, very much."  It's looking like
> we might have to do some major template changes to accommodate this.

Mmmm, juicy.

> > Wil, from my experience with localizing PHP, the blank pages are indeed only
> > something temporary, caused by some apache/PHP caching or such.
> 
> Great, thanks. :)

Hmm.  We'll still want to figure out how to force that cache to be updated or invalidated (whichever the problem is), so that we don't get the sporadic blank pages giving us spurious user reports or test failures.

(Yeah, I said "test failures".)
Assignee: nobody → clouserw
Status: ASSIGNED → NEW
Alright, check out the dev site again:

https://update-staging.mozilla.org/~clouser/v2/public/htdocs/?lang=fr_FR

I replaced all the images (again, first page only) with text+css.  I don't think it looks too bad, although I haven't been able to test it in all browsers yet.  Comments?

(I realize there are still question marks where accents should be.  I think vim or my terminal is not being UTF-8 friendly but I wanted to get comments on the layout rather than mess with that right now)
Looked at it in Firefox 1.5.0.x and Safari on mac, I don't see any problems in this direction.

The recommended extensions div though is of fixed height and cuts off after 4 lines. French is likely one of the most verbose languages, so we may be fine, but this is something to keep track off. Well, even the french test is probably a good deal shorter in real life, as it has 'Nous recommandons' twice now.

I don't see a good way to fit the french text in there, and still keep the edge that the float-like behaviour of the full-color extension icon has. And I'm afraid that using CSS float would be just a bag of trouble cross-browser-wise.

Something that came up in my head during the worldfirefoxday l10n, do you need multiple parameters in strings? If so, can localizations change the ordering in their localized content? I didn't see that possibility in the gettext-based approach on that site, just want to make sure it's on your radar.
(In reply to comment #40)
> Something that came up in my head during the worldfirefoxday l10n, do you need
> multiple parameters in strings? If so, can localizations change the ordering in
> their localized content? I didn't see that possibility in the gettext-based
> approach on that site, just want to make sure it's on your radar.

AFAIK, gettext supports this. You use something like %2s %1s, or so in such case...
(In reply to comment #41)
> (In reply to comment #40)
> > Something that came up in my head during the worldfirefoxday l10n, do you need
> > multiple parameters in strings? If so, can localizations change the ordering in
> > their localized content? I didn't see that possibility in the gettext-based
> > approach on that site, just want to make sure it's on your radar.
> 
> AFAIK, gettext supports this. You use something like %2s %1s, or so in such
> case...
> 

Smarty abstracts it one step further and ignores the data type.  That means it's just %1 through %n in whatever order you want.  (so yes, it's possible)
(In reply to comment #38) 
> Really, though, we should be looking to use text instead of
> images-containing-text pretty much everywhere.  
>
Yeah that's poor web design practice.

> Someone want to make a list of
> the images that are just or primarily text?
>
Here's your list:

feature-recommend.png - "We Recommend.... See some of our favorite (sic) extensions to get you started." *cough* favourite *cough* :D
mozilla-org.gif "mozilla" icon in yellow bar at the top of the page (probably doesn't matter) 
title.gif "mozilla update beta" (no longer used)
title-browse.gif "Browse by Category"
title-develop.gif "Develop Your Own"
title-feature-adblock.gif "Featured Extension Adblock 1.2" (no longer used)
title-firefox.gif "Firefox Add-ons beta" (also includes firefox logo. that should be split)
title-recommends.gif "Mozilla Recommends" (no longer used afaik)
title-suite.gif "Mozilla Suite Add-ons beta" (also includes suite logo. that should be split)
title-thunderbird.gif "Thunderbird Add-ons beta" (also includes tb logo. that should be split)
title-top10.gif "Top 10 Downloads" (no longer used)
title-topdownloads.gif "Top Downloads"
title-werecommend.gif "We Recommend" (no longer used)

Once we get down the track we might want to have localisable preview images too...
Looking at the French mockup example I see that the download box says :
Installez Prolongation (20 KB)

KB should be a localizable constant since this acronym depends on language (should be Ko in French, would be K&#1041; in Russian...). It should also be an HTML acronym tag to allow screenreaders to read it like <acronym title="Kilo-octets">Ko</abbr>

I also checked the page in RTL direction and the "extension top list" on the right side didn't change of direction, I think we need an arabic/hebrew localizer's opinion on this. I guess the numbering is CSS generated, specific rules would have to be applied for RTL.
(In reply to comment #44)
> It should also be an
> HTML acronym tag to allow screenreaders to read it like <acronym
> title="Kilo-octets">Ko</abbr>
> 

No, it should be inside an abbr element.

An acronym is pronounced as a word, for example "Nasa", "laser" as opposed to "BBC", "MoD". So unless the abbreviation itself is pronounced as a word, it's just an abbreviation (and at best an initialism), but not an acronym.

The only reason the acronym element is so popular is that by default Internet Explorer doesn't show a dotted underline under abbr elements.
Targetting Remora, putting back in the default bucket.
Assignee: clouserw → nobody
Target Milestone: Future → 3.0
Underway already in Remora, with partial German localization kicking around for testing even!
Flags: blocking-remora-launch+
I am proud to mark this fixed: AMOv3 contains static (gettext) as well as dynamic (DB-based) localization; its deployment version is localized into several languages, so the scope of this bug should be reached.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Verified FIXED!
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.