translations August 2006

translations@drupal.org

6 participants
6 discussions

locale support for the installer
by Gabor Hojtsy 29 Aug '06

29 Aug '06

Hi, I would appreciate if some of you could review this issue as soon as possible. If this gets in, we can provide nice translated installers to our foreign language audience, so this effect us all. http://drupal.org/node/76555 Gabor

1 0

how do I start translating the pages?
by Aziz 28 Aug '06

28 Aug '06

Hi, I am trying to get Uzbek translation of drupal going and I am confused about how to start translating the PO files. I downloaded the templates but can't open them. What program do I need to use to edit them? Can someone advise? Thanks.

3 2

Translations for HEAD and a possible string freeze
by Konstantin Käfer 24 Aug '06

24 Aug '06

Hi, during the 4.7 release cycle, I have been very active translation Drupal into my language (German). I thought that I'll share my experiences with it. If I recall it correctly, there has been a "string freeze", meaning that strings will not change anymore from a certain date on. Unfortunately almost nobody cared about that freeze and strings were constantly changing. Having translated a string just find out that two days later, the string has been dropped or tweaked is quite annoying. In the first case, the work has been entirely superfluos, in the second case, you have to search the whole string for the parts that have changed - that can be even more sophisticated than translating the entire string anew. However, I have to admit that those string changes were necessary as they updated invalid URLs that have been changed from 4.6 to 4.7. I suggest that we'll do a string freeze for the HEAD version one month after the code freeze. That would be October 1st. I think that this would give documentation patches enough time to get in after the code "freeze" (which is actually not a freeze as patches still go in, it's more of a "feature freeze") while giving translators enough time to update their translations for HEAD before it is released to the public. I urge all developers to respect that "string freeze" and only break it if absolutely necessary. That means, that all major documentation patches should get in before October 1st. If you have any suggestions, please don't hesitate to share them so we can discuss them. I'd like to know if everybody is okay with the date or if we should push or pull it. Regards, Konstantin

2 1

zh-hant vs. zh-tw
by charles chuang 07 Aug '06

07 Aug '06

Dear all, There was an issue reported in Chinese support site about zh-hant problem with Gallery2 module. He changed the locale setting form zh-hant to zh-tw, and the Drupal/Gallery2 worked properly. (http://tw-drupal.info/node/301) I don't know why we use zh-hant(zh-hants for simplified Chinese)? The zh-tw (zh-cn) is more popular in most programs. sincerely, Charles

1 0

Administrator locale aware watchdog logs
by Gabor Hojtsy 01 Aug '06

01 Aug '06

Hi, http://drupal.org/node/76588 The problem with the current watchdog() calls is that the messages are stored in the actual locale used to present that page. Ie. if you have a German, French and English section (version) of your site, watchdog logs will be recorded in all three languages intermixed with each other. Administrators reviewing logs are supposed to understand all languages used on the site to understand possible problems. This is not the desired user experience. To make the watchdog logs admin locale aware, we need to postpone the t() call to the time the log is presented to the administrator and should not t() the string on storage time. This also means that we should store the message in English, and the variables separately in a different field. I have chosen serialize()/unserialize() to store the array. We should note that for backward compatibility the previous watchdog messages should have an 'N;' value in the field (the serialization of NULL). This needs an upgrade path, which is not yet implemented in the patch, but is quite simple. Some messages in system.install for example also log stuff which is user defined, so t()-ing it is not desired. With specifying N; in the variables field, it is possible to keep those away from t(). Pros of this approach: * Actual locale used to present messages to the administrator * Messages stored before any locale is available (ie. install time messages) are later translated so easier to review and understand Cons: * Tablesorting of watchdog messages on the admin interface is not directly done using the displayed value. So eg. 404 messages with different file names will not get sorted by the filename, which is only added after the tablesort is done. * Slightly more storage requirement for the watchdog table. In my patch, I have updated the watchdog() function used to store messages and the two watchdog review interfaces in watchdog.module. As an example, I also updated the user.module (also fixing some missing theme placeholder calls). This is not a complete patch, updating of other watchdog calls and the upgrade path is also required. /Since this change requires all watchdog() calls changed to run without errors, I have not tested the change in runtime. First I would like to gather opinions on the viability of the patch to put more work into it./ Please review and comment on the issue! Gabor

1 0

Locale support for the installer (with patch)
by Gabor Hojtsy 01 Aug '06

01 Aug '06

Hi, http://drupal.org/node/76555 We discussed providing locale support for the installer. Here is a patch, which works for me, but obviously needs some discussion. What did I do to support a locale in the installer: * Wrapped all strings in the installer files in st() calls. Some having placeholder text were already wrapped. * Made possible to run the PO import in installer mode. Theme() and t() are not defined in this mode, so setting of error messages need to be dealt with as a special case for normal operation and for the installer. * The PO import in installer mode is only interested in st() calls now (no format_plural support). This does not seem to be a problem yet, since format_plural() is not needed in the installer. * In installer mode, the strings are stored in an array and retrieved from the st() function. * The tricky part is indentifying the locale to use. I stepped this over for now. The installer tries to read an installer.po file from a folder named 'locale'. If it does not exist, English is used; if it does exist, the translations in this file are used. There is no support for installer language selection in this patch. First I would like to discuss the approach taken here before stepping further. I have already updated the extractor.php script to handle st() functions, and generate an installer.pot file with all the st() wrapped strings found throughout core, regardless where they are. This enables translation teams to provide that installer.po file st() is trying to look for. Comment on the issue please! Gabor

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

translations August 2006