Hi All!

The company that I work for creates software for mobile phones. I'm working on a project to use a Web site to gather community-generated translations for some versions of that software. In other words, I'm going to have a pile of text strings from the application UI(s), and I will be feeding them through a Drupal-based site for community translation. The end result should be something similar to Google's Google In Your Language.

The current handbook section on how to contribute to translations doesn't mention the local translation servers. The following is a draft for a handbook page (or pages) to correct this. Please help by editing it (it's a wiki page), or by pointing out stuff that's incorrect, missing, or should be improved.

See also this related documentation issue.

Is there a way to automatically wrap all "translated" text with html tags? For example, the font for dz (Dzongkha/Tibetan) is really quite small compared to western fonts due to the possible height of characters in the language. It would be very useful to take any text and wrap it with tags so that I could then institute text formatting with a stylesheet, while not disturbing and western text that may be untranslated.

The Greek translation team has just released the first beta of the Greek translation for Drupal 6.x.

You are free to download, test it and report any syntactic or spelling errors at the project's issue queue.

You will find more information at the official project's homepage.

Thank you.

In the Drupal 6 translation templates, there are several strings on the form of {something}.something, such as:

I've poked around a bit in my Drupal 6 test site, but haven't been able to catch any of these strings in the wild. Can anyone tell me what kind of context they appear in?

I've just started the Scots translation of Drupal and made a wee site with l10n_server on it. My intention is, for the latter site, to have it also become a unifying point for people involved with Scots localisation in other parts of the FOSS community (I've made contact with an Ubuntu translator, for one). But, to whichever extent it's going to be used - just for Drupal or for Everything™ - it'll need some tools. Having just started out on this, I still haven't decided completely on which tools I'll want/need, so I wanted to take this up with you lot. Which tools to you need and use?

Hi!

In D5, we introduced Autolocale module, enabling users to import translations after enabling module / during installation. However, this had few caveats, as timeouts on cheap shared hosts, etc.

In D6, Autolocale is built-in core, using batch API and just works very well.

What do you think next step should be? From my point of view:

"Let Drupal automatically fetch translations from a server".

I really dont know the answer to this, and I notice its not in the Language Documentation.

http://drupal.org/node/11130
http://drupal.org/node/31714

I encourage Greek Drupal users and contributors to come and join us in our effort for a localized Drupal 6 in Greek.

Version 6RC1 is already here (6RC2 will be shortly out), the strings are frozen and all you have to do is start working with your favorite .po file editor and contribute for a smooth experience of Drupal 6 in your native language!

See this post for more information.

Thank you all!

In several languages, we need several special characters in order to make a typographically correct translation. One of them is, in French, the "unbreakable space" (and for some, its little brother, the "thin unbreakable space"). But there is no easy way to get them to work reliably with Drupal. What is the way forward?

Translation issues

Not translated, but string is present

• Menu item descriptions (patch)
• Theme descriptions (admin/build/themes)
• Theme names
• Module names
• Language direction (/admin/settings/language)
• "Navigation", "Primary links", "Secondary links" not translatable

Not translatable

• "anonymous/authenticated user" (/admin/settings/filters/add, /admin/user/permissions)
• "bundled, 2.0.34 compatible" (/admin/reports/status)
• "Installing Drupal" in the installer (and the text below) (t instead of st is used)

"Use Pager" no es "Página del Usuario" como se encuentra en la traducción actual. Debiera ser "Usar Paginación".

Use Pager
views_form.inc:294, views_ui.module:740

"Use Pager" is translated as "Página del Usuario" (User Page). It should be "Usar Paginación".

Use Pager
views_form.inc:294, views_ui.module:740

Hoy fui a adicionar una vista en uno de nuestros sitios y me "flipé" como dicen por ahí al tratar de descrifrar un par de traducciones que aparentemente forman parte de la traducción provista con el módulo...

Breadcrumb trail should not include "Home"
El hilo de ariadna, no deberia incluir "Inicio"

If checked the breadcrumb trail for this page will discard "Home". Usually you will not set this, but this is used for the Front Page View, where it IS Home and should not leave a trail to itself.
Si está chequeado, el hilo de ariadna para esta pagina descartará "Inicio". Generalmente, no se configura de esta forma.

I have completed the translation to Spanish of the Buddylist v.5.x-1.0 (2007-Jun-27) module and related files and modules (buddylist_views.inc, buddylist.module, buddylist.info, buddylist.install, buddylistautoadd.info, buddylistinvite.info, buddylistautoadd.module, buddylistinvite.module).

I have completed the translation to Spanish of the Private message v5.x-1.8 module and related files and modules (privatemsg.info, mail_edit.module, mail_edit.info).

The current es.po translation file included with the module is quite old and inaccurate, which generates plenty of confusion when used.

Update: new errors uncovered.

When running the pot file extractor, we get the following messages. They generally mean that the parser could not extract the string for the t() function because it was stored in a variable or constructed dynamically in any other way. For some strings, this is not a problem, because we have taken care of them (like date/time strings), but others won't be translateable if we don't fix them. We have to review each message and decide if there is a way the actual string lands in the translation template files, otherwise it's a bug.

O que é essa página

Para o pessoal que quer ajudar na tradução do Drupal 6 para o Brasil, esse é um esboço do manual para a tradução do Drupal 6. O objetivo final é ter uma espécie manual de estilo e um dicionário dos termos mais comuns. Isso tudo não é para complicar a vida de ninguém, é para que a gente possa ter uma tradução consistente com várias pessoas trabalhando nela. Não acho que valhe a pena incluir o workflow aqui, porque isso vai depender do tão esperado servidor de traduções que estão prometendo. Alguns dos comentários que eu fiz, se referem a coisas - dificuldades e alguns detalhes - que eu notei quando estava escrevendo a versão 2.0 da tradução do core do Drupal 5. Qualquer coisa, comentem aqui ou me mandem um email: jz.sanmartin@gmail.com (apresentação rápida: sou José San Martin. Conheço o Drupal faz um ano. Estou estudando lingüística na Unicamp. Fiz boa parte da versão 5.x-2.00 da tradução, a partir da versão anterior, de Bruno Massa).

Well, I have not been able to implement every detail I planned for this project, but nonetheless, done lots of stuff in different projects this summer. The work continues for sure, so we can get the localization server online (possibly as part of groups.drupal.org) sometime soon. There is a quick and dirty video of the localization server interface as it stands now, after the jump.

We are looking for a freelance translator for our sites:

www.egger-lerch.at
www.prinux.com

Requirements:
- Native English-speaking
- Experience or affiliation to Media and Printing Industry
- Writing skills
- Basic html knowledge (will work online at copy of site)

Scope:
- First step is the complete translation from German to English
- Next could be regular translation of new content on a monthly basis (approx. 10 pages)

Application:
- Please send quote to jobs AT egger-lerch.at by 8/22/2007

Thank you

Kurt J. Egger

As a co-maintainer of the Greek translation, I would like to inform the Greek users of Drupal that the second beta of the Greek translation for 5.x is complete.

The latest beta release is available through the project's page or directly here.

We urge you to download it and test it and report any comments or suggestions in the project's issues queue. Your feedback is valuable and we're looking forward for a stable release in the near future.

Thank you.

Now I am up to implementing the translation and plural forms user interface. I'd welcome feedback on how would this work best. The idea is to provide a pager list with some number of strings on a page to translate. If the given string needs plural versions, then we display as many input fields as that language requires. Showing the plural formula for guidance in the localization server helper block. (It is advised to click through to the Flickr page, which shows notes on the image).

Making the plural formula comprehensible seems to be a tricky question. I made it wrap nicely in case it gets too long (as in the case of quite a few of the languages we have), but the complex looking expressions do not make it easy to understand. Also, I am still in high need of feedback on my language listing / plural forms cleanup post, but with help from Gerhard, I'll be able to mail the language team maintainers too.

Dear Drupal interface translators!

Your valuable work helps Drupal to actual world domination, so we try to support you all ways possible to be able to more efficiently organize your time to translate Drupal projects (the Drupal core system itself, as well as contributed modules, themes and install profiles). Currently your work involves lots of manual steps and several "esoteric" tools:

• You either find translation templates for the actual release of the project or not. Even where templates are available, they are not always updated to the actual software release you are working with. So most of the time you need to go and generate templates yourself (previously with extractor.php, these days with potx module).
• You need to use a Gettext Portable Object editor of your choice (could be a simple text editor or a specialized tool). If you work with a contributed project, you possibly need to use msgmerge, and other command line gettext tools to merge files, prefill previously done translations, etc.
• You need to translate text already translated in other modules, and/or in Drupal core itself, unless you also merge with core translations as part of your workflow.
• Once ready, you need to get your file committed to CVS, which requires a CVS account and a good amount of branch/tagging knowledge, so you put your file to the place it belongs.
• But for already released projects, you cannot push your updated translation which were not ready in time, the translations are not coordinated.
• And on top of all this, users of modules need to manually upload PO files even if they uploaded them with the module, and obviously expected them to be imported with the install process.

As Drupal 6 feature freeze is in, and part of my SoC involvement was about making D6 better, now is a perfect time to look back on where I am. I was set out to provide solutions in the following three areas as part of my SoC project: NEW TOOLS FOR DRUPAL USERS, NEW TOOLS FOR TRANSLATION TEAMS and WEB BASED TRANSLATION TEAM SUPPORT. Let's look at the details for each:

So one part of my Google Summer of Code project is coming along nicely. Although I have posted a summary to my mentors recently, and we started to discuss some issues, they seem to be overwhelmed with work, so maybe opening up and widening the discussion is appropriate here. I had a hard time deciding whether post here or on the relevant issue (http://drupal.org/node/105986 is connected to the topic at hand), but I figured I will post a note there to this post, as this gets too long and looks into lots of directions to fit into that issue (not to make that issue a monster discussion).

See http://blog.worldwidelexicon.org/2007/05/25/simple-localization-system-s...

SLS is, as it suggests, a simple way to localize applications and websites. The system works as follows, and is easy to implement in a wide range of scenarios. Let’s imagine that you have a web user interface that you want to make available in many languages. With SLS, you simply do the following.

Guys,

Im developing a module called Live Translation. Its divided in three submodules:

• Live Translation: all end users will update all strings automatically. no more po/pot files.
• LT Extractor: similar to POTX > extract all translatable strings from all projects that your site hosts. It also provides a dynamic XML with updates, so users can download it.
• LT WebTranslation: provides a online interface to all users translate all strings. It uses OG to manage who can translate, sho can create a suggestion and who cannot help.

For Drupal 6 to be able to come out with some fundamental multilanguage support changes, reviews of some modifications and improvements are needed. There is not much time left until the code freeze, but we have a list of important issues and some possibly nice additions for you to look at. Lot of the groundwork material we developed is already in Drupal 6, which makes it possible to provide some cool user facing functionality. Now it is a good time to review the suggested changes, propose corrections and help Drupal 6 to rock in the multilanguage world.

What's already in Drupal 6? A new language subsystem which supports multiple text groups to store translations in (additionaly to the built in interface translation text group available before). There is built in support for language dependent paths and domains, right-to-left written text, with some of the themes already capable of displaying RTL pages out of the box (more to come). Interface translations are automatically imported from the file system when you install Drupal or you enable modules and themes. Posts on the site can have language associated with them, and there is a simple content translation module built into Drupal.

What is left to do? Well, the following:

Translating site settings
http://drupal.org/node/155381 - The absolute minimum to support site settings translations with a contributed module

Translating content types, user profile fields, etc.
http://drupal.org/node/155047 - Minimal object translation wrapper for content type, profile, aggregator, etc. translation

Themes still missing right-to-left display support
http://drupal.org/node/148084 - Pushbutton RTL styles
... - Garland and Minnelli RTL styles

More visible language support
http://drupal.org/node/154151 - Language-aware search

Usability improvements
http://drupal.org/node/52990 - Redoing the locale module translation web interface (see http://groups.drupal.org/node/3916)
... - Define and implement Drupal 6 translation packaging format, redesign interface translation workflow (this is done as part of Google SoC 2007)

Would be nice for multilanguage features, but probably not going to happen in Drupal 6
http://drupal.org/node/147041 or http://drupal.org/node/146033 - Two different approaches for built-in site settings translation
http://drupal.org/node/141461 - Translating any objects in Drupal (it has a good UI, but the performance is not acceptable yet)
http://drupal.org/node/141419 - Rework profile categories (has many advantages, for one being able to translate categories)
http://drupal.org/node/145164#comment-250759 - Refactor variable defaults
... - Eliminate t() from $link parameter of watchdog() calls

We have posted a patch to support object translation of certain Drupal objects (content types, user profile fields and categories, site settings, and so on) to multiple human languages. While we have clear concepts and very good ideas for the user interface (which we though before that would not be easy), performance-wise we are at crossroads. We would welcome beginner as well as expert reviewers to come and share their performance ideas about Drupal object translation, so Drupal 6 can include a mature translation infrastructure, advancing ahead of the competition. ;) We need your input!

"Introduce dynamic object translation API (optimize this!)" http://drupal.org/node/141461

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

We face two important decisions when going forward with Drupal 6 development, and these should be answered before Drupal 6 code is frozen (in one month), so the core would be ready to handle the formats desired. Drupal 6 is supposed to get autolocale functionality (no, not the module itself, but a highly polished version of it's functionality) included, having improved support for running multiple operations sequentially under tight conditions (like shared hosts). So what type of translations templates we use will impact how Drupal performs and functions. Help shape our bright future!

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!

Maybe you want to translate a drupal module or template, but can't find the original po file?
Do you want to create a new po file?
Simply use ther form at the page http://www.fagioli.biz/?q=drupal-po-file-web-generator to generate a new empy po file.

The script - even if is fully working - is in his very early stage.
Your help (user feedback or developer improvement ) is very welcome!

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.

I added two more languages for this site: Spanish and Norwegian. Remember that if you translate og you can have this site in your language.

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

Myself, Webchick and Killes have come up with two proposals for this year's SoC which involve the drupal.org infrastructure and the project module. Both of which could solve some of the worst drupal.org usability problems, and yet are interesting, flexible projects where someone with a lot of creativity and talent could have a huge, highly visible (and valuable) impact on the entire Drupal community.

Hi.

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

[scroll down for English version]

Adjunto un archivo "po" para la localización del Drupal 5.0
Es mejor que uno simplemente exportado del 4.7 porque hemos agregado muchos términos que faltan en 5.0.
Pero no es completo.
El grupo debería trabajar juntos para completarlo y normalizarlo para argentina.
El archivo está listo para utilizar en poedit (los seteos para los plurales está ajustado).
Discutiremos en la próxima reunión como proceder, entre tanto, utilizar y que les venga bien, y ... agreguen términos!

I am a web architect and a system analyst. Now, I've translated Drupal To Hebrew and initiated the creation of a drupal community in Israel. Following Gábor Hojtsy's request, Here is a use-case analysis of my expernece from the Hebrew Translation of Drupal, and with it's implementation on tens of sites, with indexation for search engine relevancy.

Recently, I've tried the Internationalization module on two of my sites, but gave it up and decided to wait for a later time. Problem is that i18n is not yet compatible with many other modules. I am a heavy user of taxonomy / category modules. The i18n module is a big step forward, but more work is needed. I need language specific taxonomy with menu integration. On one site, I have tried to use the taxonomy module, but found that the vocabulary names are not translated (nither in the node entery screens nor in the menu). On the other site, I tried to use the new category module but discovered that the node input form (and the menu) displayed all categories without language distinction.

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.

I've been translating the Esperanto interface with the large eo.po and now have CVS access and know that I need to upload the file in its individual module file. How can I split a large language po file into the smaller module po files. Thanks!

I posted this to Drupal.org a few days ago with no reply. Could someone at least point me in the right direction?

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.

I just posted an experience installing og on a multilingual site. The short version is that it ground to a halt because of the t() function. Maybe og is still a little early in it's 4.7 release, but I think it's an example of bad things happenning to good modules. Does anyone else have any experience, ideas about scaling t()? I can see there's some caching going on, and maybe I just need to adjust a cache size somewhere ...

[a while later]

aha, here it is: http://drupal.org/node/42463 - it's a problem with 'incomplete translations', and a proposed sql index fix didn't make it into 4.7 as per the discussion.

I added the Danish language to the site. This is the last language we have with og.module translation.

This language lacks the .po file for the organic groups module, which is a very much used module here. Thus, you will not be able to see the groups pages in that language until we have a translation for this module.

Do you speak Brazilian Portuguese? you can help us to fully support this language within this site. Use the .pot file (follow the link you will find in the sticky post of this group to get it) to create a new translation.

Verzweiflung, Wut und Schrecken
Begleiten ihren Sturz,
Und eine neue Welt
Entspringt auf Drupales Wort

This is almost all I can say in German, although I should say 'I can sing'. This is from the 'Die Schöpfung' by F. J. Haydn (The Creation). A wonderful piece of music I sung and played a few times which I would love to conduct at least once.

By the way, you can see I changed the ending just a bit. Forgive me for this. (Gerhard will tell you what it means...)

All this to say that I will not be able to see whether there is any bug with the new German language I added, including the og.module .po file. So please, if you spot one, let me know.

I added a new language to this site: catalan, language spoken in catalonia by more than six million people. It is my mother language so it had to be the first one to upload. Thus, if you want to browse this site in catalan... :-)

This group will be focused mainly on providing the locales for this website and will revert all its work, naturally, on the drupal community. If you want to have this site in your own language, please, translate the organic groups module and post it here (read below to see how you can do so).

Note also that there is a translation mailing list at drupal.og which is the 'official' discussion place for drupal translation topics. This group will give a 'webish' support to that list.

You can help in differents ways to translate this site:

1. Provide a translation for the .po file of the organic groups module. You can get the .pot file of this module from the cvs. We don't need the danish and german .po files which are already available, but any other language would need to get translated unless it has been already announced here.
2. If you see a bug in any string translation place a comment or upload a new fixed .po file to the correspondent story announcing the new language available (for instance, if you find abug in the catalan translation, place a comment or upload a new fixed .po file here). Obviously, if you have access to the contributions repository you better commit the new .po file there and let me know about it.