translations

translations@drupal.org

366 discussions

Re: [Translations] Drupal Localization in Nepali
by Gerhard Killesreiter 18 Sep '06

18 Sep '06

bbista(a)bellanet.org wrote: > bbista sent a message using the contact form at http://drupal.org/contact. > > I am engaged in an non profit organization (INGO) based in Nepal which is > looking after different issues related to Information and Communications > Tecnologies for Development. In this regard, we have been using and > advocating drupal as a Content Management System. Excellent! Note: It is spelled Drupal, not drupal. ;) > In this regard, we have > also tried to translate Drupal in Nepali. The tranlation work is 75% done > so far. So, I would like to know how should we be moving ahead in having > nepali translation as a part of Drupal. You need to apply for a CVS account: http://drupal.org/cvs-application > At the moment, we are also forming a Drupal Community in Nepal with a > group of enthusiastic people who are using Drupal. In this regard, I would > like to know the process to be followed to form an official nepali chapter > of Drupal which is endorsed by you guys. We don't really have endorsed chapters. We usually link to the people who ask us first. ;) Send me your URL when you have one and the spelling of "Nepali" in Nepali. Cheers, Gerhard

1 0

Re: [Translations] Maintaining a stale translation...
by Gerhard Killesreiter 15 Sep '06

15 Sep '06

lior.kesos(a)gmail.com wrote: > liorkesos sent a message using the contact form at > http://drupal.org/contact. > > Hi I'd like to upload my translation for the hebrew language. > There is a current translation for the 4.6 branch. > Yo upload my new translation do I need to open a new project? Do I need to > somehow come to an agreement or to recieve permission from the 4.6 > maintainer? > Just trying to understand the underlaying process and dynamics Please apply for an cvs account. You probably shoul dtry to contact the original maintainer and ask him if he is ok with you being the new maintainer. Cheers, Gerhard

1 0

automatic po import - how should we do it?
by Gabor Hojtsy 03 Sep '06

03 Sep '06

Hi, There is a small change in Drupal for 5.0.0, which enables you to provide translations for the installer. By providing a ja.po, it.po, de.po, hu.po etc for the default install profile (and copy the file into the default install profile folder), you can choose a foreign language in install time. (An installer.pot file will be available). Now if you have any foreign language PO files for the installer, it assumes you are interested in the locale functionality and enables that module for you. The question is how to process. The locale module should add some default languages into the database to start with. #1: Should the available installer .po files define what languages are added by default? Ie. if I have de.po, it.po and hu.po files in the default profile folder, I would have German, Italian and Hungarian languages setup automatically during install time? Once the language is set up, we should automatically import translations for enabled modules. #2: How and when should we import translations? We might get away with enabling the locale module first strictly before any other module. Then if any other module is later enabled (system.module would be the second), we would look for .po files in the "po" subfolder of that module (just like these are placed in contrib modules) and import the .po files for enabled languages, if available. #3: How should contrib modules handled? Should Drupal look for .po files in the po subfolder and import into the already set up languages? What to do with multimodule bundles, where you don't need to enable all modules (like links or ecommerce)? If you provide one .po file for the bundle, then you have many stuff to import, without a clear reason... Should we support payment-module.de.po type of filenames? Should we migrate to using these type of filenames only, so that simple de.po files will not work for standalone modules? #4: How should updates get covered? Should the module import the new translations over the old ones? We have no information to clear translations from the database (no data to look for what translation corresponds to what module, and many translations are used in multiple modules). If we import new translations over the old ones, possible user customizations will get lost. If we only import new strings, updated (fixed) translations will not get into the DB. Should we tell the user to do database backups, and sidestepp this issue with overwriting all imported strings? #5: There is an effort to support uninstallation. It is still a good question, how would that fit with locales. See questions #4 above. I would very much value your opinions. I intend to submit a patch for Drupal as soon as possible, so we can get automatic PO import in 5.0.0. Unfortunately it is not possible to create a patch, if most of the above questions are still open. Gabor

2 1

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

Check for po files in contrib/modules CVS
by Jean-Louis Réthoré 21 Jul '06

21 Jul '06

Hi, Is there a "simple" way to extract (from cvs ?) a list of modules for which a translation is available or not, in other words check if <language>.po file is present ? If we could check for their status it would be great, but it might be a much more resources-consuming task... Thanks, -- Jean-Louis Réthoré

1 0

← Newer
1
...
26
27
28
29
30
31
32
...
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