Translations

Now as we are moving into supporting translation of site settings, content types and so on on the locale module interface, it gets extremely important to streamline the translation web interface provided. As far as I see, we have the following problems with the current interface:

• you are presented with a big search form, which you need to first understand to get something to translate
• search results are presented with "edit" links, so you need to click over to the editing screen for all values you need to translate
• on the "edit" page, you get input fields for all languages, but you are possibly interested in translating more strings to one language, not one string to more languages

As far as I see, the use case of translating as many string at once as possible to one language is much more common then translating strings one by one to multiple languages. Also with site settings, content types and so on translated on the locale interface, you are not actually interested in searching in them, but going through all of them, and translating as required.

So I would suggest we move to a direction similar to how watchog (now called dblog) works:

• you get an overview screen of values to translate with a pager
• this screen can be asked for in a particular language, and would show form fields and submit buttons on the bottom ("save translations", "save translations and continue to next page", "continue to next page"), the first going back to the localization overview, the second advancing to the next page with saving, the third only advancing to the next page
• simple filters would be shown on the top, refactored from the search form

How does this sound for you? What interface would you expect from Drupal 6 to translate several parts of the system? While I still would not tell anyone to translate the built-in Drupal interface with the web interface, admin defined strings have no other practical way (most admins will not have any interest in working with a gettext toolchain).

Because there does not seem to be active development around the JavaScript localization issue, I figured I'll try to get some attention from the Javascript group. The issue at hand deals with enabling string localization in JavaScript files. Because Drupal 6 will be a big push in the multilingual direction, localizing JavaScript files should also be actively on the table. If you have time, please look into this patch or at least drop in your two cents. Thanks!

One of my three proposed subprojects for this year's Google Summer of Code was about improvements for Drupal 6 to include the autolocale functionality developed for Drupal 5. As always, putting autolocale module into core is not simply a code copy-paste issue, there are several outstanding issues that need to be worked out. The main problem is that when we need to parse and import a half of a megabyte in translation files, PHP can easily time out. So a batch processing framework was in need to process multiple operations in subsequent HTTP requests. Fortunately yched already did a big amount of groundwork on this, and Jakub Suchy tried to map the batch API to autolocale, so I only needed to dig deeper into these to try to make them work nicely together.

The extractor.php file sat there in the translation templates project waiting to get criticized to death for being hard for beginners and even people experienced with Drupal. Fortunately Raimund Bauer come along to actually disturb the waters and start to build a web based interface on top of the extraction functionality. For maintainability reasons, this resulted in the extractor.php script getting move to the resulted project.

Therefore first I would like to annonce, that extractor.php become potx-cli.php (which requires potx.inc to execute). This potx.inc file serves as the shared code base between the command line interface (CLI) script and the module. Nothing was changed in the command line interface yet, but the ugly "overhttp" mode of extractor.php was removed in favor of potx.module providing a hopefully better interface soon. So there is also a web based frontend in development to help translators extract strings from Drupal modules. But since the web interface currently largely reflects what Raimund needs (and what I tried to quickly clean up around there), we would really welcome suggestions, ideas and especially testers for the project. You can grab the latest 5.x development snapshot from here: http://drupal.org/project/potx

Hi.

Here is the Norwegian Bokmål translation of the OG module. We hope that this can be added here at groups.drupal.org

Killes once pointed out that it would be worthwhile to use Pootle for translations. Pootle is an online translation management portal. The issue was delayed last year because of hardware issues. Is it the time to float it again? Or do we plan a Drupal-based online translation portal?

Amnon
Drupal Israel / Drupal Hebrew Translation

French and Dutch have been added to groups.drupal.org so you can now browse this site using those languages. Many thanks to everyone who is helping. All the languages we have now installed are the following:

English
Brazilian Portuguese
Catalan
Danish
Dutch
French
German

These are the only languages we have in the 4.7 branch of the cvs for the organic groups module. If you want this site be 'your language' aware, please translate the .po file for og and I will be able to add it.

Besides that, keep working on the translation of all the other modules and submit your changes to the cvs. None of the languages we are using here cover more than a 60% of the drupal strings! If you want to help with this job, look for your language in http://drupal.org/project/Translations and contact the translation coordinator.

Hi there,

I would like to participate in this project, since I am in touch with a group of translators who belong to various non-commercial organizations and who would richly benefit, and I have promised to help them get up a group collaboration site for translating, and I cannot do it on my own. Even if I could, it would not be as good as a group effort.

And many would benefit from such a site.

I have hosting and could host a site for us to prototype on.
Would like to have a discussion on requirements.

Some may have noticed that drupal.co.za was offline for a while. This was due to a LARGE bunch of factors which I described in more detail on the site.

After a lot of help from Chris and Gordon, who finally isolated the problem, we are back online now, and everything seems fine, although I would appreciate it if you provide any feedback if you encounter more problems.

The upgrade to 4.7.1 will take place shortly, though, and minor downtime may be experienced again.