You intend to help to translate the Drupal interface to a language? This is the place! Look into the translator's guide in the Drupal Handbook for detailed documentation, as well as get onto the translations mailing list.
The internationalization group might also be interesting, dealing with content translation support issues in and around Drupal.
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?Read more
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
- "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" is translated as "Página del Usuario" (User Page). It should be "Usar Paginación".
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).Read more
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.Read more
Last updated by Gábor Hojtsy on Fri, 2007-10-19 12:11
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: firstname.lastname@example.org (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).Read more
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.Read more
We are looking for a freelance translator for our sites:
- Native English-speaking
- Experience or affiliation to Media and Printing Industry
- Writing skills
- Basic html knowledge (will work online at copy of site)
- 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)
- Please send quote to jobs AT egger-lerch.at by 8/22/2007
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.
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.
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:Read more
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).Read more
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.
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.
Last updated by Gábor Hojtsy on Thu, 2007-07-19 19:37
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
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).