Navigation
RSS Feeds
Localizing Komodo using Babelzilla dream team
Hi,
I'm a developer of WTS (Web Translation System) used at babelzilla.org
Babelzilla (BZ) is a free portal dedicated to Mozilla based extensions translation.
I've asked if BZ can be interested to localize KomodoEdit and Goofy (well known French localizer) says this is possible.
You can read the thread here
http://www.babelzilla.org/forum/index.php?showtopic=4433
Are you interested?
I'm not a license software expert but IMHO some problems can be found if the commercial version of KomodoEdit, KomodoIDE, want to use localizations.
Obviously the KomodoEdit locale strings are fewer that KomodoIDE so a 100% localization is not possible.
I want to enlarge the KomodoEdit community and BZ can help to spread KomodoEdit.
Feel free to ignore this request.
best regards,
davide
- Login to post comments
Davide,
We (or at least *I* :) are very interested. I'd love to see Komodo Edit localized (and Komodo IDE too, if things allow) and am willing to help where I can.
I'm not familiar with how the babelzilla process works so I don't know the best way to proceed right now.
All the localization files for Komodo Edit are here (*.dtd and *.properties files):
http://svn.openkomodo.com/openkomodo/browse/openkomodo/trunk/src/chrome/...
There are some possibilities:
- We could create an area in svn.openkomodo.com where localizers would have checkin access to add localization. I'd want that area to be *outside* of the openkomodo/trunk area to make sure there is no interference with the Komodo Edit release process. The natural place is probably starting new addons for language packs under here: http://svn.openkomodo.com/openkomodo/browse/addons
- Or we could look at having some tool to package up the en-US (and other locales) however the babelzilla process needs it to help the localization.
Regarding licensing: What license do babelzilla translations usual fall under? Is it a Creative Commons license or something like that? Are there restrictions on the usage of translations in commercial products?
Hi,
Currently, the Spicebird localization works like this:
1. Put strings on BabelZilla for translation. This part is staight forward. Take what ever directory structure is in the en-US translation, zip it into an xpi. This xpi is directory uploaded to BabelZilla.
* When you update the program with new strings, simply create a new xpi and upload, BabelZilla will take care of the update process
* When you already have some other language translations, zip them too into an xpi and BabelZilla takes care of them too.
* During any point during development/translations simply create an xpi and upload it, BabelZilla will take care of updating.
2. Let the users translate
* Only major issue I find is that comments in the original dtd/properties files are not preserved on BabelZilla. This is slated to be fixed in the upcoming new version of BabelZilla though.
3. Get strings from BabelZilla into code repository. If you are ready completely disregard the concept of offline translations, it part is easy too. Simply download the files from BabelZilla and commit into code repository. However, if you want to keep the option of having offline translations, the following issues might arise depending on how you want to maintain the translations.
* Babelzilla will remove all the comments, license headers, author names and formatting done inside the translated files. Some translators might want to retain them. For Spicebird, I want to have license headers and contributors names inside the translation files too.
* Some translations might want to do some translations offline.
To solve the last problem I have written a small script that does the following: take either the English strings or the XX-YY language strings as "template" and insert the translations done on BabelZilla onto these templates. Headers, comments and other information in these "templates" are preserved as is. Only translations are simply inserted. These are what I check into the code repository. I would be glad to improve/share this script if need be.
For Spicebird, the process has been a bit more complex because of the way Spicebird depends partly on Thunderbird translations. For Komodo, the process should be as simple as described above. BTW, teams who want to do translations completely offline are free to do so.
Above all, I found that BabelZilla has a great community who are ready to face and fix any challege that might occur in the process.
--
Sunil Mohan
In addition to point 1 above by Sunil Mohan, we are glad to say we processed a successfull test submission with a Komodo-langpack xpi.
See here
http://www.babelzilla.org/forum/index.php?showtopic=4454&st=0&p=42273&#e...
(Just register to access the WTS)
Goofy, this is an important step ahead.
--
dafi
Enhance KomodoEdit with MoreKomodo
I added some comments on that thread.
Who put that starter XPI together? Did you have a script to put that together pulling from svn.openkomodo.com/... or was it manually put together?
Where do we go from here... for getting translations other than en-US?
The XPI being talked about for uploading to BabelZilla need not be an installable language pack (if it is however, users have the advantage of downloading language packs directly from BabelZilla but the disadvantage is that the resulting translations are not trivial to check in SVN).
To make the XPI, one can get all the en-US and other language translations in the directory structure similar to the SVN tree structure, write a manifest file and zip.
I have a script for Spicebird but it caters many Spicebird specific complications.
BTW, the current version of the BabelZilla can't take two letter locale codes, so one has to convert them to and fro four letter codes when importing/exporting from BabelZilla.
Any comments/information on:
?
Ok let's say translations (if any) will be under the same triple license as the en-US files. We shall only make it clear from the start to translators that their work may be re-used in another Komodo commercial version.
---------
Thanks trentm for your interest and comments.
Now we would like to know if the development team is interested in these translations or if it is considered as useless because most developers using Komodo use (technical) English whatever their language is ?
Okay, let's try this out. :) I've added support to Komodo's build system for building a Komodo langpack XPI (based on the one goofy posted above). Here is one:
http://downloads.openkomodo.com/langpacks/Komodo-LangPack-r1712.xpi
Does that look usable? If so, do I need to submit that on babelzilla.org somewhere? Where?
(Here is the checkin adding that build support support: http://svn.openkomodo.com/openkomodo/revision?rev=1775)
hello and thanks for your concern :)
Yes it seems a usable build (submitted successfully on our mirror testsite).
The only thing that should be fixed is the version number for the xpi in the install.rdf, which remained a kind of variable "%s". I suppose it it no big problem for you.
Once logged as trentm on BabelZilla, you have just to go to this submission page
http://www.babelzilla.org/index.php?option=com_include&Itemid=100
and upload. It should be recognized as an update (since there already is a test version with same guid), then the (updated) files to translate will be available for every language on the WTS on this kind of page
http://www.babelzilla.org/index.php?option=com_wts&Itemid=51&extension=3...
Translators will register for this translation, edit files and do translations online. You will be automatically notified by mail when a new translator registers, and when they flag their work as "released" which occurs after a test/proofreading phase.
If you have questions, some of them can be answered here
http://www.babelzilla.org/content/category/3/7/25/
otherwise you are welcome to report any problem on Komodo-langpack forum
http://www.babelzilla.org/forum/index.php?showtopic=4454&hl=
else
- PM to one of the admin team: Goofy, markh, Fenian
- send a mail to siteadminATbabelzillaDOTorg
> The only thing that should be fixed is the version number for the xpi in
> the install.rdf, which remained a kind of variable "%s".
Good catch. Fixed.
I've uploaded a new build:
> Uploading Komodo-LangPack-0.1.1712.xpi OK
> Extracting Komodo-LangPack-0.1.1712.xpi OK
> Parsing install.rdf OK
> Updatecheck No previous version found
> Scanning for existing locales FAILED
> Looking for locales inside chrome.manifest
>
> OK
> Extracting .jar FAILED
> Adding to WTS OK
> Adding locale files to WTS OK
> Creating support topic OK
Thanks! We'll see how this goes.
To be honest I haven't used Babelzilla before,Engineering Logo but from what you have explained it sounds a lot more confusing to me than translations done with Rosetta at the launchpad site.
Charity Logos
Hi Trent,
The code committed by you creates a valid extension xpi file but it can't be used as langpack.
I've developed a tiny webapp (bz2kolangpack) to build an installable langpack starting from babelzilla locale tarball.
I know your skill doesn't require to take a look at my code but I've committed it at
http://dafizilla.svn.sourceforge.net/viewvc/dafizilla/webapp/bz2kolangpa...
the code writes the chrome layout directory like yours.
The most important file inside XPI is chromelist.txt, if it isn't present langpacks aren't correctly handled by Mozilla locale layout.
The file install.rdf contains em:type set to 8, the langpack corresponding value.
The webapp SVN directory list is at
http://dafizilla.svn.sourceforge.net/viewvc/dafizilla/webapp/bz2kolangpa...
--
dafi
Enhance KomodoEdit with MoreKomodo
Excuse me if I'm off topic
I've found many strings hard coded in source.
Obviously the refactoring activity has a very low priority.
Below the (partial) list of files containing hard coded strings
browse.js
compare.js
confirmrepl.js
filebrowser.js
findResultsTab.js
find_functions.js
keybindings.js
komodo.js
new.js
pref-alllangfonts.js
pref-association.js
pref-intl.js
pref-keys.js
pref-newfiles.js
pref-ruby.js
pref-servers.js
pref-web.js
run_functions.js
statusbar.js
undorepl.js
views.js
--
dafi
Enhance KomodoEdit with MoreKomodo
dafi,
Yes, you are right. Given a successful system for localizing Komodo, we'll want to look at using DTDs and .properties files for more strings in Komodo's UI.
Then, eventually, we'll also want to look at a solution for UI strings coming from Komodo's *Python* level.
Hi all,
this is my first post on this board. My name is Luca, but you can call me Pedro like all my friends do, and I'm translating Komodo in Italian. I know my English is really poor then I apologies to all for this and I hope you can understand what I am writing :P
At the present my localization is completed and on testing phase. Also the French team is testing their localizations.
I presume Czech, Portuguese, Russian and Vietnamese localization will come soon.
At the present the problem is to give users a complete translations but, as Dafi wrote, most of the strings are embedded in the code.
Are you planning a work to solve this problem?
Thanks for your attention ;)
Bye
Pedro
I totally agree with the idea of having Komodo localized, even though most developers understand and feel fine dealing with english I can ensure you that they feel even better when they can use their preferred tool in ther native language.
I have several guys working with me that would love to use it in spanish.
To be honest I haven't used Babelzilla before, but from what you have explained it sounds a lot more confusing to me than translations done with Rosetta at the launchpad site.
I have contributed with some translations to Ubuntu and some other projects and it is quite easy and painless.
No matter the choice count with me for the spanish translation.
--
Iván Gabriel
Of course the Launchpad project is great, and we have absolutely no problem if some language teams do prefer using it, we don't care for any monopoly on translations. If you have volunteers willing to translate Komodo interface into Spanish on Rosetta, possibly some Spanish translators form Babelzilla can join them (I suppose team effort is necessary)
Just a small note about that
from what you have explained it sounds a lot more confusing to me than translations done with Rosetta at the launchpad site.
Maybe what we tried to explain to the dev team on this thread sounds confusing, but I can tell you that for a translator, BabelZilla interface is quite simple, requiring almost no technical knowledge. You are welcome to give a look by yourself :)