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

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

This doesn't have to be localization of extension descriptions, but the framework of the site itself.

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.

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.

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

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)

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

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.

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.

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.

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.

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

(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".)

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.

Underway already in Remora, with partial German localization kicking around for testing even!

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.

Verified FIXED!