translations July 2007

translations@drupal.org

8 participants
10 discussions

A couple of untranslated strings in 5.x core
by Vasileios Lourdas 09 Aug '07

09 Aug '07

Hello people, I've noticed a couple of untranslated strings in Drupal 5.1. Here's the procedure I've followed: 1) Installed a fresh Drupal 5.1. 2) Enabled all modules. 3) Added the greek language as a secondary language in Localization settings page. 4) Imported the translated .po file for greek [the translation is 100% complete, the Localization settings page reports 2431/2431 (100%)]. 5) Changed the site's default language to greek. In the navigation menu in left, under Create content, the names and the descriptions for the Page and Story content types are untranslated and remain in English. Is this a bug? Should I open an issue about this? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name

4 23

Re: [translations] [Translations] Support Multilingual
by Gerhard Killesreiter 31 Jul '07

31 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hemal(a)argosoftsolutions.com schrieb: > hemal sent a message using the contact form at http://drupal.org/contact. > > Dear Sir, > > We want to use your multilingual tools in our web site. Especially we are > using four languages i.e. Spanish(Español), Italia (Italiano), > Germany(Deutsch) and US English. Our main site in English. How we can > integrate your multilingual tools in our site. > I need your support. Please see http://drupal.org/support for your available support options. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGrw3Jfg6TFvELooQRAj/CAJ9ddMRe4gIYybQqcG8sdK6RbAIwNgCeMnLX rNe0PoWFmVopmUbAYUpwNvg= =3asD -----END PGP SIGNATURE-----

1 0

translation templates for Drupal 5.2
by Gabor Hojtsy 27 Jul '07

27 Jul '07

Hi guys, I have just committed new translation templates for Drupal 5.2 to the contributions CVS repository. The previously available 5.0/5.1 (same strings) templates were tagged as 5.x-1.0, and the new strings are tagged as 5.x-2.0. A new templates package will be available here, once the automated build runs: http://drupal.org/node/162683 Otherwise you can grab the latest DRUPAL-5 version, or the DRUPAL-5--2-0 tag itself of translations/drupal-pot if you need to get to it more quickly. Changes in the strings included: - some strings removed due to Apache requirements checking removed - some string added dues to CSRF holes plugged in with confirm forms - a few clarified strings, typo fixes and better descriptions These are still not many changes, you should be able to update your translations fairly quickly. Gabor

1 0

Re: [translations] Limitations of the source-string-centric approach
by Hans Salvisberg 21 Jul '07

21 Jul '07

Gerhard Killesreiter wrote: >> I replaced this on my German-language sites with "Ihr Beitrag vom Typ >> %type wurde gespeichert." ("Your post of type %type has been created.") >> It's slightly technical, >> > It's ugly. > >> but at least it's grammatically correct. >> > Correct but ugly. > >> Grammatical errors are not acceptable, but it's often possible to come >> up with more generic phrases. >> > While that is true it makes a website often not very nice to read. We > should try to find technical solutions that allow translators to make > good translations and not force them to make ugly translations. > Yes, definitely, but in the meantime, wouldn't you agree that correctness should come before prettyness? I like Cog's suggestion, too, for this particular example. The content type doesn't really add any value to the confirmation message. Hans

1 0

Re: [translations] Limitations of the source-string-centric approach
by Hans Salvisberg 20 Jul '07

20 Jul '07

Gabor Hojtsy wrote: >> That's also an issue I have discovered, for example with the string >> "Your @type has been created." (with @type being the name of a >> content type). >> >> I'll explain the problem for people who don't understand the problem: >> Content type names have a specific gender in most languages; let's >> take "story", which translates to "Artikel" in German. The word >> "Artikel" is male, thus the sentence should be "Ihr Artikel wurde >> erstellt." (Ihr = Your). However, if we use page = Seite, we end up >> with "Ihr Seite wurde erstellt." The problem here is that "Seite" is >> female, thus requiring "Ihre" in the German language. This results in >> grammatically incorrect sentences. A wrong gender is not a minor >> issue for a native speaker, it really disturbs the reading flow and >> may shed a bad light on the site creator. >> > > The hungarian team works around this by actually translating '@type has > been created'. > I replaced this on my German-language sites with "Ihr Beitrag vom Typ %type wurde gespeichert." ("Your post of type %type has been created.") It's slightly technical, but at least it's grammatically correct. Grammatical errors are not acceptable, but it's often possible to come up with more generic phrases. Hans

3 2

Localization server project in the works
by Gabor Hojtsy 19 Jul '07

19 Jul '07

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). Continued here, you *must* read this: http://groups.drupal.org/node/5219 Gabor

1 0

Limitations of the source-string-centric approach (was: proper way to translate complicated ...)
by Cog Rusty 19 Jul '07

19 Jul '07

On 7/19/07, Gabor Hojtsy <gabor(a)hojtsy.hu> wrote: > Frederik 'Freso' S. Olesen wrote: > > 2007/7/14, Derek Wright <drupal(a)dwwright.net>: > >> [...] That's what I was hoping to hear, since I > >> agree the split approach is better for everyone. > > > > Except that for some language or other, it might make sense to switch > > order of the paragraphs, take a paragraph out, add another paragraph, > > or in some other way manipulate with the paragraphs to get the proper > > meaning. Splitting the string also risks confusion during the > > translation in the interface. > > I agree that shorter text blurbs are both easier to translate and > > easier to get people to translate (not as much work), but might also > > degrade the final outcome. > > Yes, it is unfortunately not a win-win situation. It seemed to be a good > compromise to have one t() per paragraph/list item. > > Gabor It is certainly a compromise. Stretching the idea to an extreme, if we broke everything down to single words, although words are common between many strings and the translator would have to deal with much less strings a serious translation would be obviously impossible -- single words are translated differently in different contexts, have genders, often are part of grammatical structures and idioms etc. Several times I have needed to abandon a good translation of an English term string to my language and use an awkward one instead, because in English the term happens to be common in two different contexts while in my language it is not and I have to accommodate both cases. And contributed modules join the party later to exacerbate such a problem. I suspect that in the center of these issues is the gettext system which allows an English string to have only one translation. (Perhaps the lack of context parameters in t() as well. I am not sure about that). Some time ago, for example, there was an unsolved issue with the month "May", which in English happens to be same as its abbreviation, therefore it can't have an abbreviation different from the name of the month in any other language. Or, a sting as simple as "Active" can have genders (male, female, neutral) depending on what it refers to, but here we have to choose one gender for everything (which wouldn't impress the occasional intellectual visitor of a site). The rest of the time, a little bigger chunks of text, case sensitivity or even occasional differences in the html markup of a string allow as to hack our way to a better translation. Does it seems a viable idea for the future to automatically add optional hidden text into the original English strings to identify different context, and then filter it out in the output? At least for common strings which come from a different t() I am also curious if anyone knows of any project anywhere in the world which one day might enhance or replace the gettext system to address better the issues of the single translation of a source string.

4 3

proper way to translate complicated help text with lots of HTML?
by Derek Wright 19 Jul '07

19 Jul '07

I'm reviewing some translation-related patches for project*. What's the right way to handle big, complicated help text messages that involve multiple paragraphs, ul or dl lists, etc? Here's the proposal: return t('The project module makes special use of the taxonomy (category) system. A special vocabulary, %vocabulary_name, has been created automatically.To take full advantage of project categorization, add at least two levels of terms to this vocabulary. The first level will be the basic project types, e.g., "modules", "themes", "translations".Subterms of each of these types will be the categories that users can select to classify the projects. For example, "modules" might have sub-terms including "mail" and "XML".Use the <a href="@taxonomy-admin">vocabulary admin page</a> to view and add terms.', array('@taxonomy-admin' => url('admin/ content/taxonomy/'. $vid), '%vocabulary_name' => $vocabulary->name)); Is one giant t() call preferred, or should this be split into a separate t() for each paragraph, and keep the HTML out of it, something like this: return ''. t('The project module makes special use of the taxonomy (category) system. A special vocabulary, %vocabulary_name, has been created automatically.', array('%vocabulary_name' => $vocabulary->name)) .''. t('To take full advantage of project categorization, add at least two levels of terms to this vocabulary. The first level will be the basic project types, e.g., "modules", "themes", "translations".') .''. t('Subterms of each of these types will be the categories that users can select to classify the projects. For example, "modules" might have sub-terms including "mail" and "XML".') .''. t('Use the <a href="@taxonomy-admin">vocabulary admin page</a> to view and add terms.', array('@taxonomy-admin' => url('admin/ content/taxonomy/'. $vid)) .''; ?? Thanks, -Derek

3 4

Re: [translations] [Translations] Add Esperanto/Drupalo.org
by Gabor Hojtsy 10 Jul '07

10 Jul '07

If you submit a project for the esperanto translation at http://drupal.org/node/add, *and* you create a release of the translation, it will show up. Goba simplulo(a)yahoo.com wrote: > simplulo sent a message using the contact form at > http://drupal.org/contact. > > Many of the drupal.org pages lack points of contact. Please add "Esperanto" > to this page: > http://drupal.org/community > with a link to www.drupalo.org. > > Furthermore, the full, reviewed Esperanto translation for Drupal 5 is now > in CVS, but it is not clear to us how to get it mentioned on > http://drupal.org/project/Translations > > Thanks, > > Steve >

1 0

Differences between potx generated files and drupal-pot files
by Vasileios Lourdas 08 Jul '07

08 Jul '07

Hello, I installed a fresh Drupal 5.1, enabled all modules and the latest development version from potx. Using potx, I extracted the pot files for a few core modules. I also extracted the po templates from http://drupal.org/project/drupal-pot in a separate directories. After comparing a few files from each directory, I've found that are differences between those two, although there shouldn't be any. For example: $ msgcmp --use-untranslated aggregator-module.po aggregator-module-new.po aggregator-module-new.po:60: this message is used but not defined... aggregator-module.po:83: ...but this definition is similar aggregator-module-new.po:72: this message is used but not defined in aggregator-module.po aggregator-module-new.po:76: this message is used but not defined in aggregator-module.po aggregator-module-new.po:84: this message is used but not defined... aggregator-module.po:75: ...but this definition is similar aggregator-module-new.po:88: this message is used but not defined... aggregator-module.po:55: ...but this definition is similar aggregator-module-new.po:96: this message is used but not defined in aggregator-module.po aggregator-module-new.po:104: this message is used but not defined in aggregator-module.po aggregator-module-new.po:116: this message is used but not defined in aggregator-module.po aggregator-module-new.po:120: this message is used but not defined in aggregator-module.po aggregator-module-new.po:172: this message is used but not defined... aggregator-module.po:303: ...but this definition is similar aggregator-module-new.po:184: this message is used but not defined in aggregator-module.po aggregator-module-new.po:188: this message is used but not defined in aggregator-module.po aggregator-module-new.po:192: this message is used but not defined in aggregator-module.po aggregator-module-new.po:196: this message is used but not defined in aggregator-module.po aggregator-module-new.po:220: this message is used but not defined in aggregator-module.po aggregator-module-new.po:232: this message is used but not defined... aggregator-module.po:315: ...but this definition is similar aggregator-module-new.po:332: this message is used but not defined in aggregator-module.po aggregator-module-new.po:336: this message is used but not defined in aggregator-module.po aggregator-module-new.po:340: this message is used but not defined in aggregator-module.po aggregator-module-new.po:348: this message is used but not defined in aggregator-module.po aggregator-module-new.po:392: this message is used but not defined in aggregator-module.po msgcmp: found 21 fatal errors aggregator-module.po is from drupal-pot and aggregator-module-new.po is the one extracted from potx. Obviously, there are a lot of extra messages in the potx generated file. I also noticed that there is an extra general.pot file from drupal-pot, which probably contains strings missing from the other modules of drupal-pot. drupal-pot also lacks color-module.pot. What is the rationale behind this practice? What should I do if I wanted to translate the UI? Should I use drupal-pot or potx? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

translations July 2007