translations

translations@drupal.org

366 discussions

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

Re: [translations] [Translations] Translation project
by Gerhard Killesreiter 25 Jun '07

25 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 max_xakep(a)yahoo.com schrieb: > LsasS sent a message using the contact form at http://drupal.org/contact. > > Hello! I'd like to begin Ukrainian translation project, but project > creating is not available to me. There already is such a project. Please get in touch with the maintainer: http://drupal.org/project/uk > Also i'd like to adding my translation to > contributed modules. Please, help me to do it. Please apply for a CVS account. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGf9mYfg6TFvELooQRAmVVAJ0Y5WF2/wQG7CvxW7Y5ocgUfDEg8QCgp9EI YrAaunS9EAWnWWC9h6c0hq8= =1A3t -----END PGP SIGNATURE-----

1 0

Translating module names?
by Derek Wright 19 Jun '07

19 Jun '07

http://drupal.org/node/152375 Huh? I thought you weren't supposed to put dynamic strings in t(). What's the party line on translating module names that appear in the interface? D5 core doesn't do this on the modules page, it seems... it just reads whatever is in the .info files and displays that. Thanks, -Derek

3 5

My first CVS contrib. A rap on the knuckles by WinCVS: Deprecated info format strings
by Gustavo Sánchez Muñoz 04 Jun '07

04 Jun '07

Hello, I have tried to make my first contrib to the CVS by updating some minor details in the es.po file for pathauto module (that *greggles* was so nice as to CVS due to my ignorance). I have used WinCVS (2.0.2.4) on Windows2000 (SP4). However, when finishing the "Commit" operation. WinCVS said: ************************************************* - TCL is available, shell is enabled : help (select and press enter) - cvs commit -m "Changed a few details to make it more Neutral Spanish." -- es.po (in directory H:\GRABAR\_REPOSITORIO DRUPAL 5.1\contributions\modules\pathauto\po\) /cvs/drupal-contrib/contributions/modules/pathauto/po/es.po,v <-- es.po new revision: 1.3; previous revision: 1.2 -cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. ***** CVS exited normally with code 0 ***** This message is like Ugaritic to me. I have some other modules translated for version 5.1 and I am ready to commit them as soon as I know: 1. I am not screwing anything. The first commitment is all right. 2. How do I solve the deprecation of my scripts (whatever this means). 3. How do I mark the commitment for Drupal 5.1 (that is the version I have used). Would anybody help me, please? Thank you: Gustavo Sánchez

2 1

xxx-module.hu files
by Bèr Kessels 29 May '07

29 May '07

Hello, In the contribs I just found a few xxx-module.hu po files. According to the handbook[1] they should have been named 'hu.po'. Did I miss a change in policy, and if so, can someone explain the new policy so that I can update the handbook page? If I did not miss omething, is it okay if I rename the files when I encounter them to the proper naming scheme? Bèr [1] http://drupal.org/node/11396 -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

3 5

Re: [translations] [Translations] Language
by Gabor Hojtsy 27 May '07

27 May '07

Dear Ozono, We are open to publish the Azerbaijan translation (or any other translation) if someone send it to us. Drupal works with an open community, so if someone would like to see the Azerbaijan translation, he can do it. Gabor tuncay(a)eco.gov.az wrote: > Dear Drupal administrations, > > I think its time to have Drupal in Azerbaijan language. Here in Azerbaijan > everyone likes your CMS, but the main problem is translations. All of us > are waiting for Azerbaijan Drupal CMS. We ded more projects in Drupal. But > our clients want to have Drupal in their own language. We recomend this CMS > to all of our friends. Tell us please when we could see the translations in > Azerbaijan version? > > Truly yours, > Ozono. >

2 1

updating translations: how valuable is user data after all?
by Gabor Hojtsy 24 May '07

24 May '07

Hi guys, Now Drupal 6.x-dev includes cool features to import PO files automatically at every logical step: - you can install Drupal in your foreign language, and have PO files for all enabled modules imported along automatically - when you add a new language, all translation files for enabled modules get imported automatically for that language - when you install new modules or enable themes, the translation files for these components get imported for all enabled languages This is all great and automated, contrib modules already have their PO files at the right place, and we will update the packaging scripts for Drupal 6 to package core translations properly. You might notice a pattern in the above features though: they IMPORT stuff into the database. Unfortunately we have no way in Drupal 6 to remove translations when you disable a theme or uninstall a module. We don't know what strings appeared in *only* that component, and not elsewhere in Drupal, so we can remove them without problems. For that, we would need the extractor script built into Drupal core to look through all source files of enabled components and identify the unused strings in the database. Fortunately this is doable in contrib, now that extractor has it's own Drupal module. (Of course it is doable in Drupal core my deleting all strings from the database and reimporting files for only the enabled components, but read on about the value of user data). BTW Drupal 6 core still need upgrade support for translations. So when you update a module or Drupal itself, new and corrected translations get into your database. New translations are easy again, they are just importing new stuff, which we are very good at :) Updating translations already in the DB threatens user data though. In Drupal 5 and before, we have no information about what translations a user modified on the web interface, so we don't know what was imported from available PO files and what was user defined. We can reimport stuff from the files, but can easily loose/overwrite user defined/updated strings. What can we do about not to loose user defined strings? We can easily introduce a 'modified' bit into the locale translations (target) table, just as it was in menu module in Drupal 5. That would help us from Drupal 6 onward, but it does not help us loosing user defined strings when a Drupal 5 to Drupal 6 upgrade happens. So how cautious should we be there? 1. Do not overwrite any existing translation, risking that we leave incorrect and fixed translations in the database. 2. Do overwrite existing translations on an update, risking that we overwrite user modified translations. Note that an update will not *remove* anything from the DB because we don't know what we can remove as explained above. It can *overwrite* stuff though, and problems are around these overwrites. So how should the update paths work for Drupal and for modules/themes? Gabor

3 6

Re: [translations] translations Digest, Vol 19, Issue 5
by Miguel Duarte 22 May '07

22 May '07

Hi, My 2 cents is that you should overwrite everything. At leat the pt-pt translation is still evolving and there are many old translation we updated through the time. Of course, before, you should always tell the user about that. ;) Regards, Miguel Duarte 2007/5/22, translations-request(a)drupal.org <translations-request(a)drupal.org>: > Send translations mailing list submissions to > translations(a)drupal.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.drupal.org/mailman/listinfo/translations > or, via email, send a message with subject or body 'help' to > translations-request(a)drupal.org > > You can reach the person managing the list at > translations-owner(a)drupal.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of translations digest..." > > > Today's Topics: > > 1. updating translations: how valuable is user data after all? > (Gabor Hojtsy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 May 2007 11:53:19 +0200 > From: Gabor Hojtsy <gabor(a)hojtsy.hu> > Subject: [translations] updating translations: how valuable is user > data after all? > To: development(a)drupal.org, A list for translators > <translations(a)drupal.org> > Message-ID: <4652BD8F.9000801(a)hojtsy.hu> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi guys, > > Now Drupal 6.x-dev includes cool features to import PO files > automatically at every logical step: > > - you can install Drupal in your foreign language, and have > PO files for all enabled modules imported along automatically > > - when you add a new language, all translation files for > enabled modules get imported automatically for that language > > - when you install new modules or enable themes, the translation > files for these components get imported for all enabled > languages > > This is all great and automated, contrib modules already have their PO > files at the right place, and we will update the packaging scripts for > Drupal 6 to package core translations properly. > > You might notice a pattern in the above features though: they IMPORT > stuff into the database. Unfortunately we have no way in Drupal 6 to > remove translations when you disable a theme or uninstall a module. We > don't know what strings appeared in *only* that component, and not > elsewhere in Drupal, so we can remove them without problems. For that, > we would need the extractor script built into Drupal core to look > through all source files of enabled components and identify the unused > strings in the database. Fortunately this is doable in contrib, now that > extractor has it's own Drupal module. (Of course it is doable in Drupal > core my deleting all strings from the database and reimporting files for > only the enabled components, but read on about the value of user data). > > BTW Drupal 6 core still need upgrade support for translations. So when > you update a module or Drupal itself, new and corrected translations get > into your database. New translations are easy again, they are just > importing new stuff, which we are very good at :) Updating translations > already in the DB threatens user data though. In Drupal 5 and before, we > have no information about what translations a user modified on the web > interface, so we don't know what was imported from available PO files > and what was user defined. We can reimport stuff from the files, but can > easily loose/overwrite user defined/updated strings. > > What can we do about not to loose user defined strings? We can easily > introduce a 'modified' bit into the locale translations (target) table, > just as it was in menu module in Drupal 5. That would help us from > Drupal 6 onward, but it does not help us loosing user defined strings > when a Drupal 5 to Drupal 6 upgrade happens. So how cautious should we > be there? > > 1. Do not overwrite any existing translation, risking that we leave > incorrect and fixed translations in the database. > > 2. Do overwrite existing translations on an update, risking that > we overwrite user modified translations. > > Note that an update will not *remove* anything from the DB because we > don't know what we can remove as explained above. It can *overwrite* > stuff though, and problems are around these overwrites. > > So how should the update paths work for Drupal and for modules/themes? > > Gabor > > > ------------------------------ > > _______________________________________________ > translations mailing list > translations(a)drupal.org > http://lists.drupal.org/mailman/listinfo/translations > > > End of translations Digest, Vol 19, Issue 5 > ******************************************* > -- Mobile: +351.966075978 Office: +351.217242590 Fax: +351.210125718 Skype: mcduarte2000

1 0

FYI: New way to classify releases on drupal.org
by Derek Wright 08 May '07

08 May '07

All project maintainers are encouraged to read: http://drupal.org/node/142344 thanks, -derek (dww)

1 0

Anybody I could ask general questions about Spanish translations?
by Gustavo Sánchez Muñoz 06 May '07

06 May '07

Good morning, I have just applied to the CVS to be able to submit translations for some of the contributed modules. I am posting this because I have some doubts about the workflow. I would like to know if there is something similar to a style book, translation guidelines, etc... so as to keep some consistency with the general "translation into Spanish" consensus. I don't know if there is some type of 'super translator' that reviews the translations submited, etc... Thank you Gustavo Sánchez :)

2 3

← Newer
1
...
18
19
20
21
22
23
24
...
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