Localization server project in the works

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Gábor Hojtsy's picture

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.

So we, translators have quite a few problems. I know, I am a translator in the Hungarian team as well. But Drupal developers are working on ways to solve several issues for translators.

Drupal 6 improvements

There are improvements in Drupal 6 which make setting up localized sites a lot easier:

  • The installer informs users where to get translation packs, so they can install localized from the start.
  • The installer imports translations for all enabled modules.
  • When you install modules, translation files are imported for them in all enabled languages.
  • When you add a language, translation files are imported for all enabled modules/themes.
  • When you enable a theme, translation files are imported in all enabled languages.

To make this all possible we came up with a convention: install profiles, modules and themes should have a 'translations' folder, where these translations are searched for. Note that this is a renaming of the 'po' folder convention used before, but is much less technical to be more intuitive for our users.

Anyway, this only works nicely, if there are actually translations available. So here the job turns to you: deliver even better and more translations. But we are not asking you to do this with the above toolset indefinitely. I am sponsored by Google Summer of Code to create better translation interfaces, which will automate most of the above tasks for you, and push CVS, gettext and project releases out of your way, if you are not interested in using them.

Localization server

Only local images are allowed.The plan is to have a central server on drupal.org (somewhere like t.drupal.org, or translate.drupal.org or translations.drupal.org, you get the idea), where an organic group based interface will be set up with specific tools to support translation groups. Every language will have their own group. Participating in project translations will only require a simple account registration on this site. This site will serve as a one-stop-shop for all translations, so the CVS based storage will be discontinued. What the server will do for you?

  • It will have a group set up for your language with discussion space, possibility to post guidelines and dictionaries (with generic content posting tools).
  • It will know about all projects hosted on drupal.org, and will regularly update its data about all releases available.
  • All releases will be scanned for translatable strings, and a big shared database will be used to relate these strings to projects and releases. This means that you don't need to translate 'Home' or 'Operations' more then once anymore. Because Drupal enforces translation sharing for the same strings, this site will do it too.
  • You will be able to export translation templates and work offline with your well known tools if you wish, and finally import translations to the database all on a web interface.
  • But you will be able to translate online on the web interface, string by string. This way translation projects can attract micro-contributions, if someone only has the time to translate a few strings, the web interface will surely fit nicely.
  • Translation packages will be generated for all releases of all projects, without your intervention. You don't need to think about branching or other CVS wizardry. (In fact there is no branching support planned for the initial version, so you won't be able to translate 'Home' differently for Drupal 5 and Drupal 6).

Only local images are allowed.All-in-all this might sound a bit like the Launchpad Rosetta interface run by Canonical, but is very much optimized to work with Drupal projects. I have seen some of the translation teams use project module and some use case tracker or some other home grown solution. At the Hungarian translation I work with, we developed the filebrowser module to provide an interface on top of our custom subversion repository a few years ago. The idea behind the localization server is to provide a better service for all translation teams without resorting to custom solutions to be set up by all teams themself. (There is nothing in this design which stops people to keep using external custom tools, but I hope we can work toward a better management tool, which would fit all groups).

This project is in the works for a considerable amount of time now, in fact Bruno Massa started the initial work as part of his "live translation" movement, which I took over to actually get rid all of us from the above described hassles. The reason to announcing this now is that there was no "meat" to show to you before. Now there are at least some screenshots, which show you how this service might look like. I still heavily work on the translation interface, so I cannot show that to you yet (although I know you would be eager to see it) and I welcome any feedback anyway, so feel free to post your opinions in the comments.

Localization client

There is an old feature request: provide an on-page (in-place) translation editor for Drupal sites. So when you notice translation errors or untranslated strings, you can just click and translate the strings on the same page (AJAX to the rescue), without going to the locale module interface and searching there. The localization client project (for Drupal 6.x!) deals with just that. There are new features in Drupal 6.x which make this possible, so I started a proof of concept implementation. Several people suggested that this functionality could be connected with the server, so you can share your translations with the community. This is not yet implemented, so stay tuned. The user interface of this module is also quite bare-bones, needs a nicer solution definitely. I would very much welcome people to help here out, as I would like to concentrate on the server component as part of my SoC.

Cleaning up the language list and plural information

An easy and immediate way you can help me is to read my SoC group post, and if your language is questioned for whatever reason (bad looking plural formula, bogus language code, too much language variants and so on), then please comment on the issue there. Also, if your language is not in the list, but you have translations in the Drupal.org CVS repository (or hosted your Drupal translations elsewhere), please also comment.

Comments

plural form

Christof's picture

both plural forms for Czech are correct, but the longer one used in Drupal is more accurate

Excellent news!

GoofyX's picture

This is excellent news! Drupal surely needs an on-line translation service like the one you describe.

I would also like to point out the issue raised by Cog Rusty in the translations mailing list (thread: "Limitations of the source-string-centric approach"), which we -Cog, myself and other volunteers form the greek translation team of Drupal- have faced in the past. There must be a solution (maybe not in the near future, but in the medium-term future) for translating strings in various genders and sometimes translating them differently, depending on the context they appear. This is an important issue that a lot of translators have to deal with during the translation process and they often have to translate using the same word for every context where the prototype string appears, which results in sometimes an ackward translation.

We are here to help. Keep up the great work and keep us informed of the progress.

--
... Morpheus: What is "real"? How do you define "real"? If you 're talking about what you can feel, what you can smell, what you can taste and see, then "real" is simply electrical signals interpreted by your brain...

let's discuss it

Gábor Hojtsy's picture

We are already discussing it on the mailing list, I posted some options before. Unfortunately this problem is highly unlikely to be fixed in Drupal 6, but if the discussions lead to a sane solution, Drupal 7 could have it supported. This localization server will surely bring these issues to the front, as we will immediately see when strings are used for multiple purposes.

That sounds very good

archetwist's picture

No more problems with duplicated and overwritten translations, hooray!

Drupalcentric webdesign · Drupal -- Polish support

Amazing, that's what our

meba's picture

Amazing, that's what our users wanted to help in translating. Please don't forget to support proper plural forms per language!

sure

Gábor Hojtsy's picture

I take plural support seriously both in the server and client. Look at my soc post linked above and comment there on the Czech plurals :) I am still to come up with a sane UI for plurals, but the backend support is there already.

Translation Status for Dev teams

brmassa's picture

Gabor,

now that translation process is getting even more separated from developers (they dont need even commit the po files or generate templates), its a good thing report the extraction messages on project pages. some modules use t() with variables and other errors, as well uselessly use HMTL inside the strings... dev teams should know that.

regards

massa

part of the plan

Gábor Hojtsy's picture

The system already stores extraction errors per project release, which will be visible to developers.

Swedish plural form

zoo33's picture

...looks good, as far as i understand it.

And it goes without saying that this initiative is just... fantastic. It will save me and all language maintainers a lot of work. And it will probably make the translations a whole lot better and more complete. Thank you, thank you, thank you!

/ Hannes Lilljequist – SthlmConnection

This is what I love about

robertDouglass's picture

This is what I love about Drupal. Fantastic work, Gábor. Kudos to all involved.

RTL Questions

druvision's picture

This is fantastic news! Especially the local client.

Three questions:

  1. What about RTL support? As a minimum, if the target language is RTL, translated text fields should have an 'direction:rtl' style attribute in their style declaration.

  2. You told there wil be an organic group set up for each language. Will the group set for Hebrew have an Hebrew (RTLised) interface? Will it be possible for group owners to set the group to display in their own language?

  3. Will it be possible to use the local client for RTL languages?
    When will it be possible to test it?

Thanks

Amnon

replied by mail

Gábor Hojtsy's picture

Replied by mail, but this should be interesting for others too.

Amnon Levav wrote:
> Localization Server is fantastic news! Especially the local client.
>
> Three questions:
>
> 1. What about RTL support? As a minimum, if the target language is RTL,
> translated text fields should have an 'direction:rtl' style attribute in
> their style declaration.

RTL support is tricky, because due to organic groups and views (required
by organic groups) availability is restricted to Drupal 5, I needed to
work with that version. As soon as Drupal 6 versions are available, we
can move up to Drupal 6 and ejoy all the built-in RTL support.

> 2. You told there wil be an organic group set up for each language. Will
> the group set for Hebrew have an Hebrew (RTLised) interface? Will it be
> possible for group owners to set the group to display in their own
> language?

The RTLized interface possibly depends on (1) as described above
(although it might be possible to come up with workarounds in the
meantime). Different languages per group is an organic groups feature
thankfully, so it is already done.

> 3. Will it be possible to use the local client for RTL languages?
> When will it be possible to test it?

The l10n_client project already has a Drupal 6 branch to test. The
interface is still kind of bare bones, because I am concentrating on the
server, but it works locally (without a sharing option to connect to the
server).

- install Drupal 6
- turn on locale module, add at least a language
- choose that language as the default (or set it for your personal
language in your user preferences)
- turn on l10n_client
- watch out for a form at the bottom of the pages
(if it does not appear, give yourself permission on the user
permissions page)

As I have said, this works with AJAXy translations saving (although it
does not provide a user friendly AJAX feedback). It can already be used
to translate your site page-by-page locally.

host on groups.drupal.org

moshe weitzman's picture

i would be willing to host a few modules and make UI changes so we can host these translation groups on groups.drupal.org. if you have very specialized needs you might run a separate site but if not, then lets avoid creating a new site.

fine with me

Gábor Hojtsy's picture

We have very similar needs, so hosting here is fine with me. Although I need to look into pushing my paths one level deeper, so they are clearly separated from the other features on this site (it was originally planned to host it separately).

localization.drupal.org

JohnFilipstad's picture

As the head maintainer of the Norwegian Bokmål project, and co-maintainer of the Norwegian Nynorsk project, I personally prefer having the translation teams outside of groups.drupal.org. I feel that the translation teams need a concentrated one-stop environment with the localization server and the means to discuss localization. So how about setting-up localization.drupal.org instead for this? It will be great if translation teams can also create their own pages there (like we can set-up grammar guidelines, standardized wordlist they can check in translating, help files, etc)

The norwegian community is maintaining our own localization server at http://lokalisering.drupalnorge.no in the meantime. We are supporting the Norwegian Bokmål and the Norwegian Nynorsk languages on the site.

----------------------------------------------------
Only local images are allowed.

sounds good

Nchase's picture

Germans are keeping the core translation at Goolge http://code.google.com/p/drupal-de/. They also started a translation server at
http://l10n.drupalcenter.de/ which will available for their community members to translate, and for some chosen ones to approve. The translation.drupal.org will be a great idee :) I'm looking forward for this!

Synergy is something essential - New-Tronic.com

Starting

nybegynner's picture

Then we have http://l10n.drupal.no/ up and running. This is in first place for testing.

http://www.drupal.no
Drupal in Norway (DiN)

We (www.drupalitalia.org)

thePanz's picture

We (www.drupalitalia.org) also have a beta version for localization server running on http://l10n.drupalitalia.org
It's a registered only access service for editing..

Regards

-thePanz-
thepanz.netsons.org

-thePanz-

www.drupalfr.org have also a

lilou's picture

www.drupalfr.org have also a beta version of l10n server on http://l10n.drupalfr.org

The 10 groups of localization (www.drupaler.ru)

pvasili's picture

http://drupaler.ru/translate
Russian (ru) (26134)
German (de) (8378)
Polish (pl) (5183)
Serbian (sr) (5064)
Ukrainian (uk) (4570)
Latvian (lv) (4090)
Lietuva (lt) (3166)
Bulgarian (bg) (3092)
Estonian (et) (2705)
Belarusian (be) (1669),

all (>3000) modules with drupal.org

Other languages welcome ;)

Localization Server for the Filipino language

JohnFilipstad's picture

The Filipino translation team has now set-up it's localization server at http://pili.pin.as/translations

----------------------------------------------------
Only local images are allowed.

Translations

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week