Externalized #251 localization blues

Externalized #251 localization blues

Quickfolders is a pretty smart extension for Thunderbird. You can find on its dedicated AMO page everything you need to know about its features and usage. If you browse the comments, you will see many satisfied users. Some of them are not completely convinced, but the developer manages to answer every time with great care.

options dialog

options dialog

help tips

help tips

Also, if you give a quick test to the extension, you will see there are many options available and the Help dialog is verbose enough to provide useful tips and howtos. Excellent work.

The only thing is…
this interesting extension is available in English only πŸ™

– Don’t worry, old Goofy, we shall translate it just now, I hear you saying, translators friends from BabelZilla.

– mmmh no. Because there is no locale support in this extension
That is : every string is hardcoded in a .xul or a .js file, there is NO locale subfolder, everything in the content πŸ™

So once again I added what had to be added (with the help of the great Externalize extension by my friend Davide Ficano πŸ™‚ ), and once again I sent a message with my modified version to the developer, with my usual invitation message to BabelZilla, since it is much easier to translate now, with all the strings in the locale/en-US subfolder.

The problem now is: I am reaching externalize strings process #251 in less than 3 years.

It means that extensions are (still) released without a decent locale support.

I don’t blame developers who may ignore the localization process.
I don’t blame AMO volunteer reviewers who do an tremendous work and use several quality/security tests.

I am just wondering:

WHY is it not compulsory to have a minimum (en-US or another locale) locale support in an extension to be allowed to release it on AMO?

Please, AMO Commander in Chief, add “Have a locale support” to the list of requirements! πŸ™‚

This entry was posted in Extensions around the world, Localization, Welcome. Bookmark the permalink.

7 Responses to Externalized #251 localization blues

  1. RealRaven says:

    Hi Goofy,

    I am actually contributor to the project, just found your comment on the plugin’s homepage. Since its only my first Mozilla / opensource project I found the learning curve quite steep, learning XUL, looking for boilerplate code and docs on MDC, learning message handling in JScript and fighting with Mozilla’s idiosyncrasis in dealing with OS specific layouts. When I started I added a feature for dragging the tabs (to reorder them, display subfolders and added the tabs on the options and QuickHelp text on the options dialog) [I am a UI freak].

    I am even bilingual so I was kind of toying with the idea of adding a German locale, but I thought leave this for a later version – the learning curves were already coming in thick and fast. Hey I even found a bug in one of Mozilla’s Popup menu functions.

    My personal view of localization is a very mixed one, anybody who has developed SQL code on a MS Access platform and then was asked to port it to a different language knows what its like when even language constructs (such as true and false) and parts of the API are suddenly localized (worst of all implicite casting of date/time types!!) – (not just the UI, which is bad enough, but actual SQL codes and commands as well!!) it makes it very hard to test and develop unless you have another local test system (with localized versions of all your software) handy. Another problem is support, especially when you don’t have a high bandwidth connection and VPN available. Trying to guess around on a foreign screen that is in a completely different language (I usually try to translate the English menus on the phone, and am often bemused by the awkwardness of the translations) What’s the Start button in your language? πŸ˜‰

    Therefore (although I am German) I made it my habit to only install English versions of any software (so I could get it).

    But if you hand it to us on a plate, then please, by all means send me a version of the localized code as well! I did some modifications in them meantime but I am generally quite good at merging (thanks to ExamDiff πŸ˜‰

    Oh, and thanks very much, very nice of you!

    I will help Alex to incorporate it (hope its not in zillions of lines of code).

    greets from Ireland,
    Axel (PS: you find my email address on the plugin page – I am the guy who answered most of the reviews)

  2. RealRaven says:

    PS: wow, the screenshots are quite old! At least 3 revisions back. You should check 0.9.4 its got FOlder categories and better CSS.

    I guess when the next update comes around you want a localized version πŸ˜‰

  3. Goofy says:

    hello axel πŸ™‚

    Thanks so much for your concern. It is not so often that extension developers gives feedback to a localization suggestion (less than 100 out of 250 up to now).

    I perfectly understand how boring and time consuming the localization task can be when you are a developer having already done efforts to learn how to make an extension with its various other requirements.

    As for my localized version, you can grab the xpi on my post above under “my modified version” link.

    As for the screenshots, I just ehm… borrowed them from your extension amo site (I know, hotlinking is bad :S ) πŸ™‚

    See you

  4. Goofy says:

    Screenshots updated now πŸ™‚

  5. RealRaven says:

    He Jean!

    I have actually done the localization with the help of the files you sent! And I even added a German locale (to the best of my knowledge) – so that’s already lined up for release in version 0.9.6 – just need to find a kind soul in Mozilla to review it.

    Alex, who is the original developer of the extension might also provide Dutch and French translations – and when my daughter is a bit bigger I will pay her to add the Gaelic Locale πŸ˜‰

    The dtd syntax was quite easy to deal with, everything nicely encapsulated in double quotes, I just renamed the ENTITY labels to be less clunky, so no hassles there. The only thing that became a bit unwieldy was the language resource for options.xul (see your screenshots above). It takes a bit more effort to “imagine” the layout of the dialog without the actual text in there. I think as a workaround one could either create localized XUL files (is this a valid option?) or somehow provide the texts of the default locale with the XUL file (obviously to be overwritten by the contents of the DTD files) – is that possible at all?

    The other problem was dealing with the string bundle function in the properties file, using escape sequences “\u00FC” for the German Umlauts is quite a drag – I would prefer to use HTML codes like “ä” here as they are much less oblique – but I don’t know whether string bundle supports them?

    Also its always interesting for a noob like me how many well established “3rd party”(*) tool APIs (as opposed to whats available from Mozilla) are being used (e.g. JSON, stringbundle, etc.) – hard to know what to use, the best way is obviously to find some example code thats confident about them. But usually the really cool extensions (like tabmix plus) have a frightening amount of code behind them.

    Do you know where to find a list of canonical javascript libraries (like JSON, stringbundle etc)?

    (*)might have got that one completely wrong, this is just how it looks for me πŸ™‚

    greets !
    Axel

  6. RealRaven says:

    (Except that the editor converted my umlaut html into an umlaut πŸ™‚ i meant
    & A U M L ; (without the spaces) πŸ™‚

  7. Vincent says:

    It seems that there is a request on this subject. Look at: :
    bug 461805 – Add-ons with broken locales should not be hosted or should warn the author
    The link: https://bugzilla.mozilla.org/show_bug.cgi?id=461805

Comments are closed.