translations

translations@drupal.org

366 discussions

central space for contrib pos
by Alaa Abd El Fattah 05 Aug '07

05 Aug '07

Hi, working on the Arabic translation, we have a small team of translators being paid by different projects to translate drupal. we are trying to do quality control and unify the vocabulary as much as possible (not a simple task considering how many different people's and nations speak arabic). however the requirement to store contrib po's in the contrib module's CVS directory makes it very difficult to track which modules are translated and and the whole quality control process becomes very tedious. for 4.7 translation we just dumped contrib module POs in the translations/ar directory but I'm not sure that's a good idea, I thought about having a translations/ar/contrib subdirectory or even starting a new project for Arabic contrib translations (translations/ar_contrib). so what about you? how do you organize translation of contrib modules? cheers, Alaa -- Alaa: Husband of the Grand Waragi Master http://www.manalaa.net

3 4

Empty Strings
by Martin Stadler 04 Aug '07

04 Aug '07

So empty strings in a .po file override already translated strings if I import them... I know the current system of contrib translation is far from good and people are working on it (d6, SoC...). Anyways, here's my scenario: I started translating some contrib modules I use (into German). Of course I want my work to be commited to the drupal CVS. I read the translations handbook and got used to some gettext tools, merging etc. What I did was extracting a fresh .pot file, merging it with the core de.po into the module's de.po and started translating the still empty strings. Sometimes it's too much work and it seems to be enough to only translate the strings that will be visible to the end-user leaving the rest of the strings empty. After importing and testing I filed issues in the respective projects attaching my de.po files. Now I found out that empty translation strings will override already translated strings in the override mode of the import feature of drupal. As I merged the core .po file with my .pot this is only a problem if the string doesn't exist in core but does in another contrib module with an existing translation which is already imported. I cannot merge all module's translations with the one I'm about to create. So it may happen that I override an existing translation of a contrib module with an empty string of another's module's translation. To me it makes sense to keep empty string in my translation file as I or someone else will propably continue to work on that file. But as these empty strings are soon part of the official stable modules they can override other's translations too. Of course I could import them without overriding existing strings but sometimes I want to update my translation... Is there any solution to this problem? A tool to delete the empty strings as a workaround? What kind of .po files should I commit in the future? Sorry for the long text and repetitions... Cheers, Standart

2 3

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

← Newer
1
...
17
18
19
20
21
22
23
...
37
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

translations