http://groups.drupal.org/translations Translation and internationalization of Drupal en http://groups.drupal.org/node/11282 <p>Hi All!</p> <p>The company that I work for creates software for mobile phones. I'm working on a project to use a Web site to gather community-generated translations for some versions of that software. In other words, I'm going to have a pile of text strings from the application UI(s), and I will be feeding them through a Drupal-based site for community translation. The end result should be something similar to Google's Google In Your Language.</p> <p>At the moment I'm just starting to experiment with existing Drupal i18n/l10n tools to figure out if I can do this with the existing modules or if I need to branch off from them into new use-specific modules. One thought I had was to create a node-generatator that takes each of those text strings, turns them into a node to be translated, and then I could have translators simply translate those nodes. I'm not sure if that's the best route, though.</p> <p>Any comments or ideas on that would be appreciated.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/11282#comments community translation contributed translation translation Translations Wed, 07 May 2008 08:42:02 +0000 lishevita 11282 at http://groups.drupal.org http://groups.drupal.org/node/10959 <p>The current handbook section on <a href="http://drupal.org/translators">how to contribute to translations</a> doesn't mention the local translation servers. The following is a draft for a handbook page (or pages) to correct this. Please help by editing it (it's a wiki page), or by pointing out stuff that's incorrect, missing, or should be improved.</p> <p>See also this related <a href="http://drupal.org/node/240243">documentation issue</a>.</p> <h1>Localization servers</h1> <p>In the future, all translation will be done on a localization server which will be common to all languages. For more information, see <a href="http://drupal.org/project/l10n_server">the project page for the localization server</a>. In a <a href="http://hojtsy.hu/blog/2008-jan-28/localization-server-status-update">status update in January 2008</a>, the project maintainer wrote:</p> <blockquote><p>The project is quite usable already for smaller tasks like translating a few hundred modules to one language, but it is not ready for prime-time on drupal.org yet unfortunately.</p></blockquote> <p>So, while waiting for the common server, several translation communities have started local versions. There's a list of current ones at <a href="http://drupal.org/project/l10n_server">the project page</a>.</p> <h2>How to contribute using a local server</h2> <p>Read information (if any) at the translation site and on <a href="http://drupal.org/project/Translations">the project page for the language</a> to find out if there are language specific guidelines, procedures, or glossaries.</p> <p>Register/log in at the site. Depending on how the site is configured, you may need to join a group for the langauge(s) you want to translate.</p> <p>Each string may be added as a translation or a suggestion. On some localization servers, all users can add translations, on others most users will add suggestions which will need to be approved by a smaller group of authorized users.</p> <p>You can also import translations from .po-files. <strong>Important: The server doesn't currently check if new strings are identical to old ones. In other words, if you import a translation which contains a lot of strings which are already present in the database, the result will be a lot of redundant suggestions.</strong></p> <p>The server uses Unicode fonts to create text-based icons. If your icons do not display properly, test your browser for compatibility with the <a href="http://www.fileformat.info/info/unicode/block/dingbats/utf8test.htm">Unicode 'Dingbats' block</a>. Note: It may be necessary to install a font that supports characters in the Unicode 'Dingbats' block. A list of these fonts can be found at <a href="http://www.fileformat.info/info/unicode/block/dingbats/fontsupport.htm">Font Support for Unicode Block 'Dingbats'</a>.</p> <h2>How to export translations from a local server</h2> <p>If you want a translation to import to your own site, <em>(... description to be added ...)</em></p> <p>If you want a file to contribute to CVS at drupal.org, <em>(... description to be added ...)</em></p> <h2>How to set up a local server</h2> <p><strong>Important: The module is still in heavy development. There are several known issues, and both user interface and functionality may change. Take a look at the issue queue before deciding to use the server.</p> <p>Important: Switching from editing .po files to using a localization server is a desicion which impacts the whole translation team. Take the time needed to get consensus for the change. </strong></p> <p>Prerequisites:</p> <ul> <li>Your PHP installation should have the PEAR Tar package installed (which requires zzlib support). This is required for Tar extraction (in the l10n_localpacks and l10n_drupalorg modules) and Tar generation (in the l10n_community module)<br /> <em>(... Is <a href="http://pear.php.net/package/Archive_Tar" title="http://pear.php.net/package/Archive_Tar">http://pear.php.net/package/Archive_Tar</a> the package mentioned? ...)</em></li> </ul> <p>Install the following modules:</p> <ul> <li><a href="http://drupal.org/project/potx">Translation template extractor</li> <li><a href="http://drupal.org/project/l10n_server">Localization server</a></li> <li>Optionally, <a href="http://drupal.org/project/og">Organic groups</a> and <a href="http://drupal.org/project/views">Views</a>. This is mainly useful if you want to use your server for several languages.</li> </ul> <p>Read the README-files of the modules, if present, to see if there are any additional installation instructions.</p> <p>Go to admin/build/modules and activate the following modules:</p> <ul> <li>Locale (core)</li> <li>Localization community (part of the Localization server package)</li> <li>Localization community for local packages (part of the Localization server package) ("Localization community for drupal.org" is meant for the final, common server and should <strong>not</strong> be used for local servers.)</li> <li>Translation template extractor</li> <li>Optionally: <ul> <li>Views</li> <li>Organic groups</li> <li>Localization groups (part of the Localization server package)</li> </ul> </li> </ul> <p>Go to <em>Administer &gt; Users &gt; Access control</em> (admin/user/access) and set permissions for:</p> <ul> <li>access localization community: anonymous and authenticated users</li> <li>administer localization community: admin roles only</li> <li>submit suggestions: authenticated users</li> <li>submit translations and approve suggestions: you may want to set this for autenticated users, or only for a trusted translator role</li> </ul> <p>Create a directory on your server to hold the projects to be translated.</p> <p>Go to <em>Administer &gt; Localization server &gt; Local package connector</em> (admin/l10n_server/l10n_localpacks). Under "Local packages directory" add the name of the directory you just created.</p> <p>Copy the tarball of the Drupal version(s) you want to translate to the directory you just created. (The tarball is the .tar.gz file at <a href="http://drupal.org/download" title="http://drupal.org/download">http://drupal.org/download</a>.) Do the same for any contributed modules and themes you want to translate.</p> <p>Remove unwanted languages. <em>(... description to be added ...)</em></p> <p>Import current translations. <em>(... description to be added ...)</em> You can choose to import them as approved translations or as suggestions.<br /> <strong>Important: If you import the same file twice, you will get suggestions which are identical to the approved translations.</strong></p> <p>Go to <em>Administer &gt; Site building &gt; Blocks</em> (admin/build/block). Activate the block "Translation help", choose "Configure" and under "Custom visibility settings" choose "Show this block by default, but let individual users hide it". It probably also makes most sense to check "Show block for specific roles: authenticated user"</p> <p>There's also a "Bookmarked filters" block. It doesn't do anything currently, but it hardly hurts to activate it.</p> <p>The information at the language landing pages is written for the final, central server. Change it to something which fits your site using the locale module. (See <a href="http://drupal.org/node/24593">HOWTO: Creating a customized language set to replace Drupal terminology</a> for how.)</p> <p>Each language has a landing page. If you want to create content to be shown there, you need to create a vocabulary with a term for each language called "l10n-server-[language code]" .</p> <p>See <a href="http://drupal.org/project/l10n_server">the project page</a> for information on how to get listed on the local server list.</p> <p>As with all sites, follow <a href="http://drupal.org/best-practices">best practices</a>, and remember to take backups regularily.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> Translations Wed, 23 Apr 2008 16:57:07 +0000 zirvap 10959 at http://groups.drupal.org http://groups.drupal.org/node/10738 <p>Is there a way to automatically wrap all "translated" text with html tags? For example, the font for dz (Dzongkha/Tibetan) is really quite small compared to western fonts due to the possible height of characters in the language. It would be very useful to take any text and wrap it with tags so that I could then institute text formatting with a stylesheet, while not disturbing and western text that may be untranslated.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/10738#comments i18n usability Internationalization Translations Tue, 15 Apr 2008 19:51:35 +0000 Tshering@drupal.org 10738 at http://groups.drupal.org http://groups.drupal.org/node/10483 <p>The Greek translation team has just released the first <a href="http://drupal.org/node/243145">beta</a> of the Greek translation for <strong>Drupal 6.x</strong>.</p> <p>You are free to download, test it and report any syntactic or spelling errors at the <a href="http://drupal.org/node/add/project_issue/el/bug">project's issue queue</a>.</p> <p>You will find more information at the official <a href="http://drupal.org/project/el">project's homepage</a>.</p> <p>Thank you.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/10483#comments beta1 Drupal 6.x greek translation Translations Sat, 05 Apr 2008 23:56:48 +0000 GoofyX@drupal.org 10483 at http://groups.drupal.org http://groups.drupal.org/node/9659 <p>In the Drupal 6 translation templates, there are several strings on the form of <code>{something}.something</code>, such as:</p> <div class="codeblock"><code>The {languages}.language of this node.<br />The feed&#039;s {aggregator_feed}.fid.<br />The user&#039;s role ID from {users_roles}.rid<br />The {users}.uid that created this version.<br />Block body&#039;s {filter_formats}.format; for example, 1 = Filtered HTML.<br />The block&#039;s origin module, from {blocks}.module.</code></div> <p>I've poked around a bit in my Drupal 6 test site, but haven't been able to catch any of these strings in the wild. Can anyone tell me what kind of context they appear in?<br /> My guess is that both parts should be kept untranslated, so that <code>&quot;The {languages}.language of this node.&quot;</code> becomes (in Norwegian) <code>&quot;Denne nodens {languages}.language.&quot;</code> and not <code>&quot;Denne nodens {languages}.språk.&quot;</code> Correct?</p> <p>And since these strings are going to look very weird in other languages when they contain untranslated parts, it would be useful to add a bit of explanation in the translations, such as (the equivalent of) <code>The system variable &lt;em&gt;{languages}.language&lt;/em&gt; of this node.</code> or whatever is correct. What would be a reasonably correct description?</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/9659#comments Translations Tue, 11 Mar 2008 19:44:20 +0000 zirvap 9659 at http://groups.drupal.org http://groups.drupal.org/node/9556 <p>I've just started the <a href="http://drupal.org/project/sco">Scots translation of Drupal</a> and made a <a href="http://scots.freso.dk/">wee site with l10n_server</a> on it. My intention is, for the latter site, to have it also become a unifying point for people involved with Scots localisation in other parts of the FOSS community (I've made contact with an Ubuntu translator, for one). But, to whichever extent it's going to be used - just for Drupal or for Everything™ - it'll need some tools. Having just started out on this, I still haven't decided completely on which tools I'll want/need, so I wanted to take this up with you lot. Which tools to <em>you</em> need and use?</p> <ol> <li>A terminology database/dictionary is, of course, essential. Something more dynamic than a plain page/node would probably be best. Perhaps something like <a href="http://drupal.org/project/glossary">glossary</a>/<a href="http://drupal.org/project/g2">G2 Glossary</a>? Or an inventive use of taxonomy? What have you done?</li> <li>Forums are also an obvious addition. I personally find that this is done well enough with the core module, but what do you think? Do you find you need to use other modules to extend on forum.module? Do you use any hacks or code snippets for the forum?</li> <li>Language links. Dictionaries, other translation sites, interesting sites in the language of the project, etc. would be good to link to. Are any of you utilising such link databases? If so, how? A contrib module? <a href="http://drupal.org/project/cck">CCK</a>?</li> <li>And I'm sure there are many other things one could include on such a site. What do <em>you</em> use, apart from the above? Why and how does it work?</li> </ol> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/9556#comments Translations Sat, 08 Mar 2008 23:30:38 +0000 Freso 9556 at http://groups.drupal.org http://groups.drupal.org/node/9420 <p>Hi!</p> <p>In D5, we introduced Autolocale module, enabling users to import translations after enabling module / during installation. However, this had few caveats, as timeouts on cheap shared hosts, etc.</p> <p>In D6, Autolocale is built-in core, using batch API and just works very well.</p> <p>What do you think next step should be? From my point of view:</p> <p>"Let Drupal automatically fetch translations from a server".</p> <p>Imagine an user, enabling a module. Drupal polls Drupal.org (or something else), downloads a translation, imports it. No need to download any package, packages for modules will be smaller.</p> <p>This could be done for installer and/or contribs.</p> <p>What do you think and how do you think we can do this?</p> <p>Just my $0.02:<br /> - Installer is a great place for this, contrib may not be (Translations are already packed with contribs)<br /> - Gabor mentioned (at DrupalCon in Boston) that it may be done using Localization client. Is it wise? Any other approaches?<br /> - I can imagine a very easy implementation using curl()/fopen()/xmlrpc() (having a failback) to query Drupal.org/... for a translation, download it, extract (how to do this without Archive/Tar.php?) and import.</p> <p>Please post your ideas so we can eventually get this to D7 :-)</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/9420#comments internationalization locale translations Internationalization Translations Wed, 05 Mar 2008 22:09:57 +0000 meba@drupal.org 9420 at http://groups.drupal.org http://groups.drupal.org/node/8403 <p>I really dont know the answer to this, and I notice its not in the Language Documentation.</p> <p><a href="http://drupal.org/node/11130" title="http://drupal.org/node/11130">http://drupal.org/node/11130</a><br /> <a href="http://drupal.org/node/31714" title="http://drupal.org/node/31714">http://drupal.org/node/31714</a></p> <p>Neither one talks about if HTML is allowed or converted. It would be nice if this was mentioned. Even if its a Comment, that would be great. Can the Translations group please answer if you need to put HTML within the translations .po file, and/or the Admin interface... and then can we make changes/Comments to the appropriate documentation. There is a few places in both documents this information should/could go... anyone have suggestions...</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/8403#comments Beginner Documentation Translations Wed, 23 Jan 2008 20:01:23 +0000 GreenJelly 8403 at http://groups.drupal.org http://groups.drupal.org/node/8044 <p>I <u>encourage <strong>Greek</strong> Drupal users and contributors</u> to come and <a href="http://groups.drupal.org/hellas">join</a> us in our effort for a localized <strong>Drupal 6</strong> in <strong>Greek</strong>.</p> <p>Version 6RC1 is already here (6RC2 will be shortly out), the strings are frozen and all you have to do is start working with your favorite .po file editor and contribute for a smooth experience of Drupal 6 in your native language!</p> <p>See <a href="http://groups.drupal.org/node/8043">this post</a> for more information.</p> <p>Thank you all!</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/8044#comments Drupal 6 greek translation Translations Mon, 07 Jan 2008 16:08:13 +0000 GoofyX@drupal.org 8044 at http://groups.drupal.org http://groups.drupal.org/node/8007 <p>In several languages, we need several special characters in order to make a typographically correct translation. One of them is, in French, the "unbreakable space" (and for some, its little brother, the "thin unbreakable space"). But there is no easy way to get them to work reliably with Drupal. What is the way forward?</p> <p>In traditional (X)HTML, we use <code>&amp;nbsp;</code> to render an "unbreakable space" and <code>&amp;thinsp;</code> to render a "thin unbreakable space". <strong>But that's not a solution in Drupal</strong>, because in several context, the string is passed to <a href="http://api.drupal.org/api/function/check_plain">check_plain()</a>. These strings are rendered to the user as-is, with an ugly <code>&amp;nbsp;</code>.</p> <p>The solution would be to use Unicode equivalent characters (<code>U+00A0</code> for the <code>NO-BREAK SPACE</code> and <code>U+202F</code> for the <code>NARROW NO-BREAK SPACE</code>). <strong>But</strong>, there is no PO-Editor (nor the I18N server) that manage those special spaces. There is no easy way to input them, and no visual way to distinguish them from normal spaces.</p> <p>I see three ways forward:</p> <ol> <li>Change <a href="http://api.drupal.org/api/function/check_plain">check_plain()</a>, in order to allow some entities to go thru. I think most of them could, except perhaps <code>&amp;gt;</code> and <code>&amp;lt;</code>.</li> <li>Change the translation packaging scripts of d.o, in order to replace at packaging time most entities to their Unicode equivalent; or</li> <li>Change the locale import function, in order to replace these entities at loading time.</li> </ol> <p>I think this is a very important issue, which could be solved before the release of Drupal 6 in order to make it truly an international release.</p> <p>What do you think?</p> <p>Damien</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/8007#comments Translations Sun, 06 Jan 2008 17:45:42 +0000 Damien Tournoud 8007 at http://groups.drupal.org http://groups.drupal.org/node/7843 <h1>Translation issues</h1> <h2>Not translated, but string is present</h2> <ul> <li>Menu item descriptions <a href="http://drupal.org/node/176748">(patch)</a></li> <li>Theme descriptions (admin/build/themes)</li> <li>Theme names</li> <li>Module names</li> <li>Language direction (/admin/settings/language)</li> <li>"Navigation", "Primary links", "Secondary links" not translatable</li> </ul> <h2>Not translatable</h2> <ul> <li>"anonymous/authenticated user" (/admin/settings/filters/add, /admin/user/permissions)</li> <li>"bundled, 2.0.34 compatible" (/admin/reports/status)</li> <li>"Installing Drupal" in the installer (and the text below) (t instead of st is used)</li> <li>"Drupal already installed" (/install.php after installation; installer.pot is not imported, but contains these strings)</li> <li>permission names with custom node type names* (/admin/user/permissions)</li> <li>"view" (last column on /admin/reports/dblog)</li> <li>Region names in themes (/admin/build/blocks): "Left/Right sidebar, Footer"</li> </ul> <h2>Only translated on install</h2> <ul> <li>"Forums" (page title on /admin/content/forum)</li> <li>Action descriptions (/admin/settings/actions)</li> </ul> <h1>Other flaws:</h1> <ul> <li>OpenID authentication contains ?destination= argument which makes "allowing forever" a pita</li> <li>Lots of notices at /install.php?profile=default (when other languages are available)</li> <li>Pretty module names at /admin/settings/actions, /admin/reports/dblog</li> </ul> <p>* missing permission names are:</p> <ul> <li>create page content</li> <li>create story content</li> <li>delete any page content</li> <li>delete any story content</li> <li>delete own page content</li> <li>delete own story content</li> <li>delete revisions</li> <li>edit any page content</li> <li>edit any story content</li> <li>edit own page content</li> <li>edit own story content</li> </ul> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/7843#comments Translations Wed, 26 Dec 2007 13:57:02 +0000 kkaefer@drupal.org 7843 at http://groups.drupal.org http://groups.drupal.org/node/6987 <p>"Use Pager" no es "Página del Usuario" como se encuentra en la traducción actual. Debiera ser "Usar Paginación".</p> <blockquote><div class="codeblock"><code>Use Pager<br />views_form.inc:294, views_ui.module:740</code></div> </p></blockquote> <p><hr /></p> <p>"Use Pager" is translated as "Página del Usuario" (User Page). It should be "Usar Paginación".</p> <blockquote><div class="codeblock"><code>Use Pager<br />views_form.inc:294, views_ui.module:740</code></div> </p></blockquote> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/6987#comments Español Translations Wed, 07 Nov 2007 21:25:48 +0000 Carlos Miranda Levy@drupal.org 6987 at http://groups.drupal.org http://groups.drupal.org/node/6986 <p>Hoy fui a adicionar una vista en uno de nuestros sitios y me "flipé" como dicen por ahí al tratar de descrifrar un par de traducciones que aparentemente forman parte de la traducción provista con el módulo...</p> <blockquote><p><i>Breadcrumb trail should not include "Home"</i><br /> <b><code>El hilo de ariadna, no deberia incluir &quot;Inicio&quot;</code></b></p></blockquote> <blockquote><p>If checked the breadcrumb trail for this page will discard "Home". Usually you will not set this, but this is used for the Front Page View, where it IS Home and should not leave a trail to itself.<br /> <b><code>Si está chequeado, el hilo de ariadna para esta pagina descartará &quot;Inicio&quot;. Generalmente, no se configura de esta forma.</code></b></p></blockquote> <p>El hilo de quién??? Si esa niña no es usuaria de mi site... Sólo al revisar en admin/settings/locale/string/search pude descubrir que algún anti-imperialista, o que considera que el público es más versado en mitología griega que en cuentos infantiles, decidió más acertado traducir el rastro de migajas de pan como hilo de Ariadna...</p> <p>Ambas corresponden al archivo:</p> <p>views_form.inc</p> <p><hr /></p> <p>"Breadcrumb trail" is translated as "Hilo de Ariadna" (Ariadna's thread), someone somewhere apparently swears that we are more versed in Greek mythology than in children's bedtime stories. :p</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/6986#comments Español Translations Wed, 07 Nov 2007 21:09:14 +0000 Carlos Miranda Levy@drupal.org 6986 at http://groups.drupal.org http://groups.drupal.org/node/6752 <p>I have completed the translation to Spanish of the Buddylist v.5.x-1.0 (2007-Jun-27) module and related files and modules (buddylist_views.inc, buddylist.module, buddylist.info, buddylist.install, buddylistautoadd.info, buddylistinvite.info, buddylistautoadd.module, buddylistinvite.module).</p> <p>I reviewed and updated the translation strings in the es.po file included with the module, then updated and enhanced them with the buddylist.pot translation template file included; I then used the potx module to extract strings from modules and files under my sites/all/modules/buddylist folder and proceeded to review, correct and complete all translation strings.</p> <p>Since I'm not sure where to contribute back the completed Spanish translation file, I'm uploading it here and as an issue under the buddylist module project page.</p> <p>If there is a special place to upload module translations, pls let me know.</p> <p>I changed the file extension to .txt, because the system does not allow attaching files with .po extensions. Just download the file and change the extension back to .po.</p> <p><hr /></p> <p>He completado la traducción al español del módulo Buddylist v.5.x-1.0 (2007-Jun-27) y sus archivos y módulos relacionados (buddylist_views.inc, buddylist.module, buddylist.info, buddylist.install, buddylistautoadd.info, buddylistinvite.info, buddylistautoadd.module, buddylistinvite.module).</p> <p>Revisé y actualicé las cadenas en el es.po incluido, luego actualicé el es.po con el template buddylist.pot incluido; a seguidas extraje todos los strings de los módulos y archivos en mi sites/all/modules/buddylist folder usando el módulo potx y procedí a revisar, corregir y completar todas las cadenas de traducción.</p> <p>Como no estoy seguro de dónde contribuir a la comunidad con el archivo de traducción al español completo, lo estoy subiendo acá y como un issue en la página de proyecto del módulo buddylist.</p> <p>Si hay algún lugar especial en el cual colgarlo, por favor déjenme saberlo.</p> <p>Cambié la extensión del archivo a .txt, porque el sistema no permite subir acá archivos con la extensión .po. Al obtener el archivo, es sólo cosa de renombrarlo con la extensión .po.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/6752#comments buddylist contributed modules español spanish traducciones translations Argentina Buenos Aires Chile Colombia Español Social Networking Sites Spain Translations Thu, 25 Oct 2007 05:33:28 +0000 Carlos Miranda Levy@drupal.org 6752 at http://groups.drupal.org http://groups.drupal.org/node/6709 <p>I have completed the translation to Spanish of the Private message v5.x-1.8 module and related files and modules (privatemsg.info, mail_edit.module, mail_edit.info).</p> <p>The current es.po translation file included with the module is quite old and inaccurate, which generates plenty of confusion when used.</p> <p>I reviewed and updated the translation strings in the es.po file included with the module, then updated and enhanced them with the privatemsg.pot translation template file included; I then used the potx module to extract strings from modules and files under my sites/all/modules/privatemsg folder and proceeded to review, correct and complete all translation strings.</p> <p>Since I'm not sure where to contribute back the completed Spanish translation file, I'm uploading it here and as an issue under the privatemsg module project page - <a href="http://drupal.org/project/privatemsg" title="http://drupal.org/project/privatemsg">http://drupal.org/project/privatemsg</a> - and on my blog - <a href="http://www.socinfo.com/drupal/privatemsg/translation/spanish" title="http://www.socinfo.com/drupal/privatemsg/translation/spanish">http://www.socinfo.com/drupal/privatemsg/translation/spanish</a> -.</p> <p>If there is a special place to upload module translations, pls let me know.</p> <p>I changed the file extension to .txt, because the system does not allow attaching files with .po extensions. Just download the file and change the extension back to .po.</p> <p><hr /></p> <p>He completado la traducción al español del módulo Private message v5.x-1.8 y sus archivos y módulos relacionados (privatemsg.info, mail_edit.module, mail_edit.info).</p> <p>El archivo de traducción es.po actualmente incluido en el módulo es bastante viejo, desactualizado e impreciso, generando confusión al ser usado.</p> <p>Revisé y actualicé las cadenas en el es.po incluido, luego actualicé el es.po con el template privatemsg.pot incluido; a seguidas extraje todos los strings de los módulos y archivos en mi sites/all/modules/privatemsg folder usando el módulo potx y procedí a revisar, corregir y completar todas las cadenas de traducción.</p> <p>Como no estoy seguro de dónde contribuir a la comunidad con el archivo de traducción al español completo, lo estoy subiendo acá y como un issue en el la página de proyecto del módulo privatemsg - <a href="http://drupal.org/project/privatemsg" title="http://drupal.org/project/privatemsg">http://drupal.org/project/privatemsg</a> y en mi blog - <a href="http://www.socinfo.com/drupal/privatemsg/translation/spanish" title="http://www.socinfo.com/drupal/privatemsg/translation/spanish">http://www.socinfo.com/drupal/privatemsg/translation/spanish</a> -.</p> <p>Si hay algún lugar especial en el cual colgarlo, por favor déjenme saberlo.</p> <p>Cambié la extensión del archivo a .txt, porque el sistema no permite subir acá archivos con la extensión .po. Al obtener el archivo, es sólo cosa de renombrarlo con la extensión .po.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/6709#comments contributed modules español privatemsg spanish traducciones translations Argentina Brazil Buenos Aires Chile Colombia Español Latin America Madrid Area Spain Translations Tue, 23 Oct 2007 18:24:28 +0000 Carlos Miranda Levy@drupal.org 6709 at http://groups.drupal.org http://groups.drupal.org/node/6077 <p><strong>Update: new errors uncovered.</strong></p> <p>When running the pot file extractor, we get the following messages. They generally mean that the parser could not extract the string for the <code>t()</code> function because it was stored in a variable or constructed dynamically in any other way. For some strings, this is not a problem, because we have taken care of them (like date/time strings), but others won't be translateable if we don't fix them. We have to review each message and decide if there is a way the actual string lands in the translation template files, otherwise it's a bug.</p> <ul> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/common.inc?view=co">includes/common.inc</a>:1143<br /> <code>t(gmdate($c,$timestamp),array(),$langcode)</code></del><br /> <a href="http://drupal.org/node/174459"><strong>(patch for AM/PM)</strong></a> committed</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/common.inc?view=co">includes/common.inc</a>:1074<br /> <code>format_plural(floor($timestamp/$value),$key[0],$key[1],array(),$langcode)</code></del><br /> (doesn't need fix: the used strings do have a special treatment in potx.inc)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:313<br /> <code>t($form_state['values']['name'])</code></del><br /> (used as name of predefined language and that list is already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:319<br /> <code>t($predefined[$langcode][0])</code></del><br /> (used as name of predefined language and that list is already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:401<br /> <code>t($languages[$langcode]-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:494<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:642<br /> <code>t($predefined[$langcode][0])</code></del><br /> (used as name of predefined language and that list is already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:798<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:2142<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:2145<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:2149<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:2160<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:2204<br /> <code>t($value[0])</code></del><br /> (used as name of predefined language and that list is already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:2208<br /> <code>t($value[0])</code></del><br /> (used as name of predefined language and that list is already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/locale.inc?view=co">includes/locale.inc</a>:1151<br /> <code>$t($message,$vars)</code></del><br /> (used in _locale_import_message() which is already parsed as t() in potx)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/menu.inc?view=co">includes/menu.inc</a>:396<br /> <code>t($item['title'])</code></del><br /> (doesn't need fix: variable contains menu title which is already folded into the template)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/menu.inc?view=co">includes/menu.inc</a>:399<br /> <code>t($item['title'],menu_unserialize($item['title_arguments'],$map))</code></del><br /> (doesn't need fix: variable contains menu title which is already folded into the template)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/menu.inc?view=co">includes/menu.inc</a>:413<br /> <code>t($item['description'])</code></del><br /> (doesn't need fix: variable contains menu description which is already folded into the template)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/dblog/dblog.admin.inc?view=co">modules/dblog/dblog.admin.inc</a>:69<br /> <code>t($dblog-&amp;gt;type)</code></del><br /> (watchdog type names are collected by potx)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/dblog/dblog.admin.inc?view=co">modules/dblog/dblog.admin.inc</a>:129<br /> <code>t($dblog-&amp;gt;type)</code></del><br /> (watchdog type names are collected by potx)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/dblog/dblog.admin.inc?view=co">modules/dblog/dblog.admin.inc</a>:241<br /> <code>t($dblog-&amp;gt;message,unserialize($dblog-&amp;gt;variables))</code></del><br /> (watchdog type names are collected by potx)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/locale/locale.module?view=co">modules/locale/locale.module</a>:206<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/locale/locale.module?view=co">modules/locale/locale.module</a>:450<br /> <code>t($language-&amp;gt;name)</code></del><br /> (most sites only use built-in language names, which are already translatable)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/menu/menu.admin.inc?view=co">modules/menu/menu.admin.inc</a>:361<br /> <code>t('Menu name can not be longer than '.MENU_MAX_MENU_NAME_LENGTH_UI.' characters.')</code></del><br /> <a href="http://drupal.org/node/174267"><strong>(patch)</strong></a> committed</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/system.admin.inc?view=co">modules/system/system.admin.inc</a>:569<br /> <code>t($file-&amp;gt;info['description'])</code></del><br /> (doesn't need fix: the module description is already folded into the template files)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/system.admin.inc?view=co">modules/system/system.admin.inc</a>:917<br /> <code>t($info['description'])</code></del><br /> (doesn't need fix: the module description is already folded into the template files)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/system.admin.inc?view=co">modules/system/system.admin.inc</a>:1792<br /> <code>t($description)</code></del><br /> (doesn't need fix: the module description is already folded into the template files)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/system.admin.inc?view=co">modules/system/system.admin.inc</a>:1914<br /> <code>t($package)</code></del><br /> (doesn't need fix: the package name is already folded into the template files)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.admin.inc?view=co">modules/user/user.admin.inc</a>:525<br /> <code>t($perm)</code></del><br /> (doesn't need fix: variable contains permission name which gets special handling)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.admin.inc?view=co">modules/user/user.admin.inc</a>:587<br /> <code>t($key)</code></del><br /> (doesn't need fix: variable contains permission name which gets special handling)</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?view=co">modules/user/user.module</a>:1758<br /> <code>t($permission)</code></del><br /> (doesn't need fix: variable contains permission name which gets special handling, but the array index is wrong)<br /> <a href="http://drupal.org/node/174440"><strong>(patch</strong> for issue in the same line<strong>)</strong></a> committed</p> </li> <li> <p><del>Invalid marker content in <a href="http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/user/user.module?view=co">modules/user/user.module</a>:3126<br /> <code>t($string,array('%a'=&amp;gt;$filters[$type]['title'],'%b'=&amp;gt;$options[$value]))</code></del><br /> <a href="http://drupal.org/node/174270"><strong>(patch)</strong></a> committed</p> </li> </ul> <p>Update by Gábor Hojtsy: here is the actual list of errors. Most are harmless, but I did not yet have the time to look through them properly.</p> <p>Invalid marker content in includes/actions.inc:304<br /> * watchdog('actions',format_plural($count,'One orphaned action (%orphans) exists in the actions table. !link','@count orphaned actions (%orphans) exist in the actions table. !link',array('@count'=&gt;$count,'%orphans'=&gt;$orphans,'!link'=&gt;$link),'warning'))</p> <p>Invalid marker content in includes/bootstrap.inc:716<br /> * watchdog($type,$message,$variables=array(),$severity=WATCHDOG_NOTICE,$link=NULL)</p> <p>Invalid marker content in includes/common.inc:732<br /> * t($string,$args=array(),$langcode=NULL)</p> <p>Invalid marker content in includes/common.inc:1001<br /> * t($singular,$args,$langcode)</p> <p>Invalid marker content in includes/common.inc:1008<br /> * t($plural,$args,$langcode)</p> <p>Invalid marker content in includes/common.inc:1013<br /> * t($singular,$args,$langcode)</p> <p>Invalid marker content in includes/common.inc:1015<br /> * t($plural,$args,$langcode)</p> <p>Invalid marker content in includes/common.inc:1019<br /> * t(strtr($plural,array('@count'=&gt;'@count['.$index.']')),$args,$langcode)</p> <p>Invalid marker content in includes/common.inc:1159<br /> * t(gmdate($c,$timestamp),array(),$langcode)</p> <p>Invalid marker content in includes/common.inc:1165<br /> * t('!long-month-name '.gmdate($c,$timestamp),array('!long-month-name'=&gt;''),$langcode)</p> <p>Invalid marker content in includes/common.inc:340<br /> * watchdog('page not found',check_plain($_GET['q']),NULL,WATCHDOG_WARNING)</p> <p>Invalid marker content in includes/common.inc:369<br /> * watchdog('access denied',check_plain($_GET['q']),NULL,WATCHDOG_WARNING)</p> <p>Invalid marker content in includes/common.inc:998<br /> * format_plural($count,$singular,$plural,$args=array(),$langcode=NULL)</p> <p>Invalid marker content in includes/common.inc:1090<br /> * format_plural(floor($timestamp/$value),$key[0],$key[1],array(),$langcode)</p> <p>Invalid marker content in includes/install.inc:601<br /> * st($string,$args=array())</p> <p>Invalid marker content in includes/locale.inc:313<br /> * t($form_state['values']['name'])</p> <p>Invalid marker content in includes/locale.inc:319<br /> * t($predefined[$langcode][0])</p> <p>Invalid marker content in includes/locale.inc:401<br /> * t($languages[$langcode]-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:494<br /> * t($language-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:642<br /> * t($predefined[$langcode][0])</p> <p>Invalid marker content in includes/locale.inc:798<br /> * t($language-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:2142<br /> * t($language-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:2145<br /> * t($language-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:2149<br /> * t($language-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:2160<br /> * t($language-&gt;name)</p> <p>Invalid marker content in includes/locale.inc:2204<br /> * t($value[0])</p> <p>Invalid marker content in includes/locale.inc:2208<br /> * t($value[0])</p> <p>Invalid marker content in includes/locale.inc:1145<br /> * _locale_import_message($message,$file,$lineno=NULL)</p> <p>Invalid marker content in includes/locale.inc:1151<br /> * $t($message,$vars)</p> <p>Invalid marker content in includes/menu.inc:423<br /> * t($item['title'])</p> <p>Invalid marker content in includes/menu.inc:426<br /> * t($item['title'],menu_unserialize($item['title_arguments'],$map))</p> <p>Invalid marker content in includes/menu.inc:440<br /> * t($item['description'])</p> <p>Invalid marker content in misc/drupal.js<br /> * Drupal.t(singular, args)</p> <p>Invalid marker content in misc/drupal.js<br /> * Drupal.t(plural, args)</p> <p>Invalid marker content in misc/drupal.js<br /> * Drupal.t(plural.replace('@count', '@count['+ index +']')</p> <p>Invalid menu 'title' definition found in block_menu() in modules/block/block.module on line 166</p> <p>Invalid marker content in modules/dblog/dblog.admin.inc:69<br /> * t($dblog-&gt;type)</p> <p>Invalid marker content in modules/dblog/dblog.admin.inc:129<br /> * t($dblog-&gt;type)</p> <p>Invalid marker content in modules/dblog/dblog.admin.inc:241<br /> * t($dblog-&gt;message,unserialize($dblog-&gt;variables))</p> <p>Invalid menu 'title' definition found in help_menu() in modules/help/help.module on line 23</p> <p>Invalid marker content in modules/locale/locale.module:206<br /> * t($language-&gt;name)</p> <p>Invalid marker content in modules/locale/locale.module:436<br /> * t($language-&gt;name)</p> <p>Invalid menu 'title' definition found in node_menu() in modules/node/node.module on line 1323</p> <p>Invalid menu 'description' definition found in node_menu() in modules/node/node.module on line 1328</p> <p>Invalid menu 'title' definition found in node_menu() in modules/node/node.module on line 1332</p> <p>Invalid marker content in modules/system/system.admin.inc:598<br /> * t($file-&gt;info['description'])</p> <p>Invalid marker content in modules/system/system.admin.inc:938<br /> * t($info['description'])</p> <p>Invalid marker content in modules/system/system.admin.inc:1813<br /> * t($description)</p> <p>Invalid marker content in modules/system/system.admin.inc:1935<br /> * t($package)</p> <p>Invalid marker content in modules/system/system.module:1103<br /> * watchdog('file system',t('Could not delete temporary file "%path" during garbage collection',array('%path'=&gt;$file-&gt;filepath)),'error')</p> <p>Invalid menu 'title' definition found in system_menu() in modules/system/system.module on line 261</p> <p>Invalid menu 'title' definition found in system_menu() in modules/system/system.module on line 385</p> <p>Invalid marker content in modules/system/system.install:2435<br /> * watchdog('php',$msg,array(),WATCHDOG_WARNING)</p> <p>Invalid marker content in modules/system/system.install:2651<br /> * watchdog('legacy',$admin_setting)</p> <p>Invalid menu 'title' definition found in trigger_menu() in modules/trigger/trigger.module on line 104</p> <p>Invalid marker content in modules/user/user.admin.inc:532<br /> * t($perm)</p> <p>Invalid marker content in modules/user/user.admin.inc:594<br /> * t($key)</p> <p>Invalid marker content in modules/user/user.module:1756<br /> * t($permission)</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/6077#comments Drupal Dojo Drupal for Good Translations Mon, 10 Sep 2007 14:32:13 +0000 kkaefer@drupal.org 6077 at http://groups.drupal.org http://groups.drupal.org/node/6068 <h3>O que é essa página</h3> <p>Para o pessoal que quer ajudar na tradução do Drupal 6 para o Brasil, esse é um esboço do manual para a tradução do Drupal 6. O objetivo final é ter uma espécie manual de estilo e um dicionário dos termos mais comuns. Isso tudo não é para complicar a vida de ninguém, é para que a gente possa ter uma tradução consistente com várias pessoas trabalhando nela. Não acho que valhe a pena incluir o workflow aqui, porque isso vai depender do tão esperado servidor de traduções que estão prometendo. Alguns dos comentários que eu fiz, se referem a coisas - dificuldades e alguns detalhes - que eu notei quando estava escrevendo a versão 2.0 da tradução do core do Drupal 5. Qualquer coisa, comentem aqui ou me mandem um email: <a href="mailto:jz.sanmartin@gmail.com">jz.sanmartin@gmail.com</a> (apresentação rápida: sou José San Martin. Conheço o Drupal faz um ano. Estou estudando lingüística na Unicamp. Fiz boa parte da versão 5.x-2.00 da tradução, a partir da versão anterior, de Bruno Massa).</p> <h3>Introdução: o estilo da tradução</h3> <p>É preciso manter um estilo consistente na tradução. É preciso, portanto, escolher um estilo para o texto da tradução. Não é, certamente, um problema muito grave. Não temos tanta liberdade como, por exemplo, teríamos em um texto literário. Além disso, a maioria dos textos (exceto os da ajuda) são muito curtos e não causam muito problema. Mesmo assim, definir, em linhas gerais, qual seria o estilo da tradução do Drupal ajuda na hora de escolher um termo ao invés de outro ou decidir que uma estrutura da frase seria mais apropriada que outra.</p> <p>Para cada site Drupal, há dois grupos de pessoas usando: os administradores e os visitantes. Certas frases, como por exemplo as de ajuda, só vão ser lidas pelos administradores. Outras, como os títulos de blocos ou as frases do formulário de comentário, vão ser lidos pelos visitantes também. Quando for traduzir alguma coisa, pense em quem vai ler. Os administradores têm mais conhecimento e paciência para aprender do que os visitantes. Com os visitantes, podemos assumir apenas que eles sabem o que é um post de um blog ou um email. Com os administradores, podemos introduzir os termos mais técnicos do Drupal, como bloco, cache e peso.</p> <p>Além disso, é bom lembrar que há dois tipos de administradores: aqueles que sabem bastante de informática e do Drupal (e portanto, o jargão de informática) e aqueles que não sabem. Com os usuários avançados, nem precisamos nos preocupar muito, pois - não é verdade? - eles nem vão ler a maioria dos textos, mesmo.</p> <p>São três tipos diferentes de usuários do site, cada qual com suas necessidades:</p> <ol> <li>os visitantes, que precisam de frases simples, com apenas as palavras comuns do português da Internet. As frases para esse público são aquelas que aparecem em lugares como os formulários de comentário, os blocos e na página de contato.</li> <li>os administradores não-avançados, que precisam de textos bem compreensíveis e termos fáceis. As frases para esses público são aquelas que aparecem nas páginas de administração mais simples e na maioria dos textos de ajuda.</li> <li>os administradores avançados, que precisam de textos muito precisos e rápidos de ler. Eles entendem bem o jargão da informática e do Drupal e mais do que isso: entendem melhor o jargão do que o não-jargão. As frases para esse público são as de algumas páginas de administração e alguns poucos textos de ajuda.</li> </ol> <p>Por isso, pense em quem vai ler antes de traduzir. As palavras usadas, podem ser diferentes em cada contexto. "Post" ou mesmo "página" podem ser usados quando apresentadas para o público não-avançado, enquanto o público avançado vai preferir "node". Ou então, "categoria" e "taxonomia". Cada termo vai ser de acordo com quem o texto se dirige. (por sinal, é exatamente como fazem no original do Drupal em inglês)</p> <p>O texto final deve ser em português brasileiro, fluente e claro, com frases curtas e termos compreensíveis.</p> <h4>Manual de estilo</h4> <ul> <li><strong>Palavras inglesas no português:</strong> não tem porque evitar palavras do inglês se elas foram bem compreendidas pelo público brasileiro. Por exemplo, melhor usar "blog", "email", "site" e "post" ao invés de qualquer outra coisa que a gente invente. Por outro lado, é bom tomar cuidado com o jargão. Quem trabalha informática tem uma tolerância muito maior à palavras inglesas do que o público em geral, pelo simples fato de que todos na informática lêem bem inglês (e praticamente, só lêem inglês no trabalho) e o resto do público, não. É sempre bom considerar se a palavra inglesa é realmente aceita pelo público em geral ou se é aceita somente no jargão de informática. Por exemplo, "deletar" ainda que bem compreendido, é um jargão de informática, e portanto um pouco menos compreendido do que "apagar". "Overview" ou "frontpage" são outros exemplos: podem ser compreendidos por muitos, mas não por todos. <p>Por sorte, essa questão não é tão crítica: o Drupal em inglês é bem escrito e evita palavras pouco compreensíveis. Não tem, portanto, muitas palavras na tradução que vão causar problemas na hora de criar o dicionário.</li> <li><strong>Expressões recorrentes:</strong> o Drupal está repleto de frases repetidas, diferentes só por uma palavra ou outra. É importante manter a consistência. Se você perceber que uma frase parece se repetir por toda a tradução, procure todo o conjunto de frases semelhantes e traduza todas de uma vez só. Além, é claro, de incluir no dicionário. Uma frase que se repetia muito na tradução do Drupal 5, por exemplo, era:<br /> <blockquote><p>For more information please read the configuration and customization handbook <a>Comments page</a>. -- Para maiores informações, por favor leia o <a>manual de configurações de comentários</a>.</p></blockquote> </li> <li><strong>aspas e apóstrofes:</strong> use sempre as "aspas" e não siga o que está no original. Não use 'apóstrofes' senão no caso uma citação dentro de outra, como em:<br /> <blockquote><p>Ele disse: "clique no link 'novo menu'".</p></blockquote> <p>Note que esse caso não apareceu no core do Drupal 5 e provavelmente não vai aparecer em momento nenhum do Drupal 6.</li> <li><strong>Futuro:</strong> prefira sempre a forma "vai ser" ao invés de "será". Isso dá para a tradução um tom menos formal e mais fluente.</li> <li><strong>ter no sentido de existir:</strong> não tem problema nenhum, é perfeitamente aceitável. É o mais comum no português brasileiro. Também é perfeitamente aceitável transitar entre o uso de "ter" e de "haver".</li> <li><strong>orações reduzidas em infinitivo:</strong> o original em inglês nos faz tender a traduzir as frases usando a seguinte estrutura:<br /> <blockquote><p>...um menu para o visitante poder navegar</p></blockquote> <p>Frases desse tipo (com subordinadas reduzidas de infinitivo), especialmente se forem muito longas, podem ser difíceis de ler. É melhor escrever na forma não reduzida, como em:</p> <blockquote><p>... tem um menu para que o visitante possa navegar</p></blockquote> </li> <li><strong>ou então:</strong> muitas vezes, em listas longas, onde no original se lê "or", é bom traduzir por "ou então", ao invés de simplesmente "ou". Isso porque "ou então" é mais enfático e ajuda o leitor a separar as duas alternativas quando o texto é muito longo. Por exemplo:<br /> <blockquote><p>For more information see W3C's <a>HTML Specifications</a> or use your favorite search engine to find other sites that explain HTML.</p> </p></blockquote> <blockquote><p>Para maiores informações, consulte as <a>especificações do HTML</a>, da W3C, ou então use algum mecanismo de busca para achar algum outro site que fale sobre HTML.</p> </p></blockquote> </li> <li><strong>diferenças culturais:</strong> aproveitando a frase acima, vale mencionar: não traduza tudo literalmente. Algumas vezes, o jeito com que um americano fala com o usuário é diferente do jeito com que um brasileiro fala. (por "americano", entenda-se alguém, de qualquer nacionalidade, falando o dito "inglês internacional") Ao traduzir alguma coisa, pense se você escreveria isso em português em alguma situação qualquer. No exemplo acima, temos a expressão "favorite search engine" pode parecer muito normal na boca de um americano, mas duvido que algum brasileiro diga com naturalidade "seu mecanismo de busca favorito". Não, o que um brasileiro diria é "o que você quiser, qualquer um, de sua escolha". Esse é só um caso e listar todos os casos não é possível aqui, mas basta ficar atento.</li> <li><strong>plural:</strong> em todo o original, se usa uma palavra no sentido genérico. Por exemplo, "administrators can" significando não "mais de um administrador", mas sim "um administrador qualquer". No português brasileiro, isso também é possível, mas resolvi dar a preferência por usar no singular com um, traduzindo "administrators can" por "um administrador pode".</li> <li><strong>ter de / ter que:</strong> <li><strong>ênclises:</strong> (pronome -lo, -la, -lhe, como em "apagá-lo, ativá-lo") devem ser evitadas. Já caíram faz muito do português brasileiro culto falado e está em declínio até mesmo no português brasileiro culto escrito. Pronomes em ênclise dão um tom muito artificial ao texto. Alternativas (em ordem da melhor à pior): omitir o pronome oblíquo, usar uma passiva, repetir o substantivo, usar ênclise (o apagar, o ativar), usar "isso". As formas, do tipo "apagar ele" e "ativar ele", que são a norma no português brasileiro culto falado, ainda não são completamente aceitas no texto escrito. Até podemos usar "apagar ela" em alguns casos que "soar bem", mas deve se ter cautela. A decisão é caso por caso e depende do bom senso do tradutor.</li> <li><strong>falsos cognatos e outros problemas:</strong> preste atenção se aquela palavra que parece com uma do português quer dizer aquilo mesmo. Alguns termos do inglês são traduzidas por mais de um termo em português. Outras só podem ser traduzidas por uma paráfrase (uma descrição). O caso mais radical, ao meu ver, é a palavra "unique". Não quer dizer, de modo algum, "único" e traduzir assim só causa problemas. Por exemplo, um texto diz que você precisa digitar um "unique name". Se traduzirmos por um "único nome", vai parecer que o texto diz que você está digitando dois nomes, quando na verdade está digitando um nome repitido. Por exemplo:<br /> <blockquote><p>Filter format names need to be unique. A format named %name already exists.</p></blockquote> <p>é traduzido por:</p> <blockquote><p>Os nomes de formatos não podem ser repetidos. Um formato com o nome "%name" já existe.</p></blockquote> <p> As palavras, como "unique", que causam problemas de tradução devem ser incluidas no dicionário.</li> </ul> <h3>Dicionário de termos técnicos</h3> <ul> <li><strong>body</strong> - corpo</li> <li><strong>cache</strong> - cache</li> <li><strong>category</strong> - categoria</li> <li><strong>checkbox</strong> - <del>checkbox</del> caixa de seleção</li> <li><strong>core</strong> - núcleo <del>(ou core? - a discutir)</del></li> <li><strong>cron</strong> - agendador de tarefas</li> <li><strong>directory</strong> - pasta</li> <li><del><strong>engine</strong> - engine</del> - indefinido</li> <li><strong>frontpage</strong> - página inicial / página principal</li> <li><strong>mail</strong> - email (e não e-mail, nem mail, nem correio eletrônico)</li> <li><strong>module</strong> - módulo<br /> comments module, forum module, xxxxx module - módulo Comentários, módulo Fórum, módulo Xxxxx </li> <li><strong>node</strong> - node (para usuários avançados), post (para a maioria das situações) ou página (para quando não houver risco de confusão)</li> <li><strong>outline</strong> (book) - esboço (tradução confusa, passível de revisão)</li> <li><strong>overview</strong> - visão geral</li> <li><strong>post</strong> - enviar, postar ou publicar</li> <li><strong>search</strong> - buscar</li> <li><strong>taxonomy</strong> - taxonomia / categoria</li> <li><strong>toolkit</strong> - toolkit</li> <li><strong>throttle</strong> - regulador/regular</li> <li><strong>update</strong> - atualizar</li> <li><strong>upload</strong> - na maioria dos casos, "enviar" (como em "enviar arquivos"). Quando precisar ser mais específico, use "fazer upload"</li> <li><strong>weight</strong> - peso</li> </ul> <p>*traduções discutíveis. a decidir</p> <h3>Dicionário de termos técnicos de informática</h3> <ul> <li><strong>add</strong> - </li> <li><strong>administer</strong> - administrar</li> <li><strong>administration section/screen</strong> - área de administração de ...</li> <li><strong>administrator</strong> - administrador</li> <li><strong>box of content</strong> - caixa de texto</li> <li><strong>custom</strong> - palavra problemática. Embora em alguns casos pode ser traduzida como "personalizado" pode confundir o leitor. Um tema "custom" é um tema que o dono do site fez para o site dele. Um tema "personalizado", por exemplo, parece querer dizer que cada usuário do site tem um modificou o tema de acordo com suas vontades... "Customizado" não é muito corrente no português brasileiro e não quer dizer muita coisa para boa parte do público. Talvez o preferível é traduzir "custom" ora por "personalizado", ora por "próprio", ora por "adaptar" e ora por uma paráfrase como "que você mesmo criou", "como você quiser".</li> <li><strong>delete</strong> - apagar</li> <li><strong>enable</strong> - ativar</li> <li><strong>enabled</strong> - ativado ou ativo<br /> use um ou outro, dependendo do contexto. Se importa apenas o fato de estar ativo, use "ativo". Se é importante ressaltar a ação de ativar em um tempo passado recente, use "ativado". Exemplos:</p> <blockquote><p>Quando o bloco estiver ativo, ...<br /> Depois que o bloco for ativado...<br /> Apenas blocos que estão ativados são exibidos.</p></blockquote> <p>É um pouco arbitrário. A escolha final é do tradutor. </li> <li><strong>enter</strong> - digite/digitar</li> <li><strong>more informations</strong> - maiores informações (e nunca, mais informações)</li> <li><strong>named</strong> - chamado/a</li> <li><strong>note that</strong> - note que</li> <li><strong>overview</strong> - visão geral</li> <li><strong>read</strong> - no contexto de "read" o manual/a documentação, use "consulte"</li> <li><strong>remove</strong> - apagar / remover<br /> use remover apenas se for remover de algum lugar específico, como "remover do livro". Se o sentido for simplesmente o de "apagar da existência" (ou "remover do site", o que dá no mesmo), é preferível usar "apagar"</li> <li><strong>unique</strong> - Não quer dizer, de modo algum, "único" e traduzir assim só causa problemas. Por exemplo, um texto diz que você precisa digitar um "unique name". Se traduzirmos por um "único nome", vai parecer que o texto diz que você está digitando dois nomes, quando na verdade está digitando um nome repitido. Por exemplo:<br /> <blockquote><p>Filter format names need to be unique. A format named %name already exists.</p></blockquote> <p>é traduzido por:</p> <blockquote><p>Os nomes de formatos não podem ser repetidos. Um formato com o nome "%name" já existe.</p></blockquote> </ul> <h3>Dicionário de expressões recorrentes</h3> <p>(a ser preenchido quando começarmos a trabalhar com a tradução do Drupal 6)</p> <ul> <li><strong>%username's blog</strong> - blog de %username</li> </ul> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/6068#comments brazil portuguese translation Brazil Translations Sun, 09 Sep 2007 16:52:14 +0000 José San Martin@drupal.org 6068 at http://groups.drupal.org http://groups.drupal.org/node/5726 <p>Well, I have not been able to implement every detail I planned for this project, but nonetheless, done lots of stuff in different projects this summer. The work continues for sure, so we can get the localization server online (possibly as part of groups.drupal.org) sometime soon. There is a quick and dirty video of the localization server interface as it stands now, after the jump.</p> <p>My work involved modifications in the following existing projects:</p> <ul> <li> <p>Drupal 6 core modifications</p> <ul> <li>made it possible to import translations automatically (Jakub Suchy was great help in testing!)</li> <li>defined a new packaging format for translations</li> <li>refactored locale.inc to support a gettext export API</li> <li>made it possible to implement localization client with t() modifications</li> </ul> </li> <li> <p>Potx module modifications</p> <ul> <li>API-ified the extractor, so it is possible to store strings directly into a Drupal database</li> </ul> </li> <li> <p>Project module modifications</p> <ul> <li>Made it possible to retrieve project releases for all core compatibility versions (dww helped a lot here)</li> <li>Making it possible to retrieve a list of projects on the server (again, dww is great, work is still underway)</li> </ul> </li> </ul> <p>Developed these new modules:</p> <ul> <li> <p>Localization server for Drupal 5.x (some parts inherited from Bruno Massa, completely rewritten from the group up)</p> <ul> <li>Automated project listing discovery from updates.drupal.org</li> <li>Automated string scanning of releases</li> <li>Organic groups based group translation interface to form translation groups</li> <li>Share translations between different projects and releases</li> <li>Various filtering options for translations</li> <li>Import already done translations (support desktop tools and onsite Drupal translations)</li> <li>Export translation templates (support desktop tools)</li> </ul> </li> <li> <p>Localization client for Drupal 6.x</p> <ul> <li>Provides on-page traslation for Drupal sites (no need to use the cumbersome locale module interface)</li> </ul> </li> </ul> <p>Stuff that was not done yet, but is/was planned:</p> <ul> <li> <p>Localization client</p> <ul> <li>Improved UI: in-place translation instead of on-page, by identifying strings on the page; also better AJAX feedback</li> <li>Act as a real client to the server, make it possible to submit translations directly to the server</li> </ul> </li> <li> <p>Localization server</p> <ul> <li>Provide a simple XML interface for project module to get translation stats, and pull this data from project module</li> <li>Make the generated (exported) release packages available for download statically, not just generate them online</li> <li>Implement suggestions! (Although there is help text and UI in the module now which tells you it support suggestions, it actually does not support it yet)</li> <li>Improve UI: dim the toolbar buttons when they are not active (ie. extended information already provided, textarea already shown)</li> </ul> </li> </ul> <p><a href="http://groups.drupal.org/node/5150">Look back at the overview</a> if you missed how all these are connected. Also <a href="http://hojtsy.hu/drop/LocalizationServer.swf">check out this quick and dirty demo of some of the features of the localization server.</a> (This video was made with Jing, which does not make it possible to edit/refine it, and it also enforces a 5 minute limit, which can be quite good to distill the most important information into a demonstration, but can also be limiting if you have something to tell which would be slightly more. So you write a blog post too.).</p> <p>All-in-all although I am not entirely satisfied with the state of the projects right now (the client is unfortunately still kind of bare bones), I think I was able to deliver cool solutions this summer, and not planning on stopping development anytime soon. By this time, the drupal.org infrastructure related consequences of the modules show, so we will see how these fit into the infrastructure after some discussion with them. (Ie. when and where will you see a test site, where will the final version reside).</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/5726#comments SoC 2007 Translations Mon, 20 Aug 2007 15:15:24 +0000 Gábor Hojtsy 5726 at http://groups.drupal.org http://groups.drupal.org/node/5658 <p>We are looking for a freelance translator for our sites:</p> <p><a href="http://www.egger-lerch.at" title="www.egger-lerch.at">www.egger-lerch.at</a><br /> <a href="http://www.prinux.com" title="www.prinux.com">www.prinux.com</a></p> <p>Requirements:<br /> - Native English-speaking<br /> - Experience or affiliation to Media and Printing Industry<br /> - Writing skills<br /> - Basic html knowledge (will work online at copy of site)</p> <p>Scope:<br /> - First step is the complete translation from German to English<br /> - Next could be regular translation of new content on a monthly basis (approx. 10 pages)</p> <p>Application:<br /> - Please send quote to <strong>jobs AT egger-lerch.at</strong> by 8/22/2007</p> <p>Thank you</p> <p>Kurt J. Egger</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> Translations Thu, 16 Aug 2007 22:47:42 +0000 kje@drupal.org 5658 at http://groups.drupal.org http://groups.drupal.org/node/5472 <p>As a co-maintainer of the Greek translation, I would like to inform the Greek users of Drupal that the <strong>second beta</strong> of the Greek translation for <strong>5.x</strong> is complete.</p> <p>The latest beta release is available through the <a href="http://drupal.org/project/el/">project's page</a> or directly <a href="http://ftp.drupal.org/files/projects/el-5.x-1.0-beta2.tar.gz">here</a>.</p> <p>We urge you to download it and test it and report any comments or suggestions in the <a href="http://drupal.org/node/add/project_issue/el/bug">project's issues queue</a>. Your feedback is valuable and we're looking forward for a stable release in the near future.</p> <p>Thank you.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/5472#comments drupal 5 greek translations Translations Mon, 06 Aug 2007 23:59:53 +0000 GoofyX@drupal.org 5472 at http://groups.drupal.org http://groups.drupal.org/node/5351 <p><a href="http://flickr.com/photos/gaborhojtsy/927554163/"><img src="http://farm2.static.flickr.com/1060/927554163_a14c74d98d_m.jpg" align="right" alt="Plural translation UI" hspace="10" vspace="5" /></a>Now I am up to implementing the translation and plural forms user interface. I'd welcome feedback on how would this work best. The idea is to provide a pager list with some number of strings on a page to translate. If the given string needs plural versions, then we display as many input fields as that language requires. Showing the plural formula for guidance in the localization server helper block. (It is advised to click through to the Flickr page, which shows notes on the image).</p> <p>Making the plural formula comprehensible seems to be a tricky question. I made it wrap nicely in case it gets too long (as in the case of quite a <a href="http://groups.drupal.org/node/5216">few of the languages we have</a>), but the complex looking expressions do not make it easy to understand. Also, I am still in high need of feedback on my <a href="http://groups.drupal.org/node/5216">language listing / plural forms cleanup post</a>, but with help from Gerhard, I'll be able to mail the language team maintainers too.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/5351#comments SoC 2007 Translations Sat, 28 Jul 2007 14:12:20 +0000 Gábor Hojtsy 5351 at http://groups.drupal.org http://groups.drupal.org/node/5219 <p>Dear Drupal interface translators!</p> <p>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). Currently your work involves lots of manual steps and several "esoteric" tools:</p> <ul> <li>You either find translation templates for the actual release of the project or not. Even where templates are available, they are not always updated to the actual software release you are working with. So most of the time you need to go and generate templates yourself (previously with extractor.php, these days with potx module).</li> <li>You need to use a Gettext Portable Object editor of your choice (could be a simple text editor or a specialized tool). If you work with a contributed project, you possibly need to use msgmerge, and other command line gettext tools to merge files, prefill previously done translations, etc.</li> <li>You need to translate text already translated in other modules, and/or in Drupal core itself, unless you also merge with core translations as part of your workflow.</li> <li>Once ready, you need to get your file committed to CVS, which requires a CVS account and a good amount of branch/tagging knowledge, so you put your file to the place it belongs.</li> <li>But for already released projects, you cannot push your updated translation which were not ready in time, the translations are not coordinated.</li> <li>And on top of all this, users of modules need to manually upload PO files even if they uploaded them with the module, and obviously expected them to be imported with the install process.</li> </ul> <p>So we, translators have quite a few problems. I know, I am a translator in the Hungarian team as well. But Drupal developers are working on ways to solve several issues for translators.</p> <h3>Drupal 6 improvements</h3> <p>There are improvements in Drupal 6 which make setting up localized sites a lot easier:</p> <ul> <li>The installer informs users where to get translation packs, so they can install localized from the start.</li> <li>The installer imports translations for all enabled modules.</li> <li>When you install modules, translation files are imported for them in all enabled languages.</li> <li>When you add a language, translation files are imported for all enabled modules/themes.</li> <li>When you enable a theme, translation files are imported in all enabled languages.</li> </ul> <p>To make this all possible we came up with a convention: install profiles, modules and themes should have a 'translations' folder, where these translations are searched for. Note that this is a renaming of the 'po' folder convention used before, but is much less technical to be more intuitive for our users.</p> <p>Anyway, this only works nicely, if there are actually translations available. So here the job turns to you: <em>deliver even better and more translations</em>. But we are not asking you to do this with the above toolset indefinitely. I am sponsored by Google Summer of Code to create better translation interfaces, which will automate most of the above tasks for you, and push CVS, gettext and project releases out of your way, if you are not interested in using them.</p> <h3>Localization server</h3> <p><a href="http://flickr.com/photos/gaborhojtsy/852826647"><img src="http://farm2.static.flickr.com/1318/852826647_c966c13990_m.jpg" align="right" alt="Languages overview" hspace="10" vspace="5" /></a>The plan is to have a central server on drupal.org (somewhere like t.drupal.org, or translate.drupal.org or translations.drupal.org, you get the idea), where an organic group based interface will be set up with specific tools to support translation groups. Every language will have their own group. Participating in project translations will only require a simple account registration on this site. This site will serve as a one-stop-shop for all translations, so the CVS based storage will be discontinued. What the server will do for you?</p> <ul> <li>It will have a group set up for your language with discussion space, possibility to post guidelines and dictionaries (with generic content posting tools).</li> <li>It will know about all projects hosted on drupal.org, and will regularly update its data about all releases available.</li> <li>All releases will be scanned for translatable strings, and a big <em>shared</em> database will be used to relate these strings to projects and releases. This means that you don't need to translate 'Home' or 'Operations' more then once anymore. Because Drupal enforces translation sharing for the same strings, this site will do it too.</li> <li>You will be able to export translation templates and work offline with your well known tools if you wish, and finally import translations to the database all on a web interface.</li> <li>But you will be able to translate online on the web interface, string by string. This way translation projects can attract micro-contributions, if someone only has the time to translate a few strings, the web interface will surely fit nicely.</li> <li>Translation packages will be generated for all releases of all projects, without your intervention. You don't need to think about branching or other CVS wizardry. (In fact there is no branching support planned for the initial version, so you won't be able to translate 'Home' differently for Drupal 5 and Drupal 6).</li> </ul> <p><a href="http://flickr.com/photos/gaborhojtsy/852826637"><img src="http://farm2.static.flickr.com/1438/852826637_b186be9839_m.jpg" align="right" alt="Server home" hspace="10" vspace="5" /></a>All-in-all this might sound a bit like the Launchpad Rosetta interface run by Canonical, but is very much optimized to work with Drupal projects. I have seen some of the translation teams use project module and some use case tracker or some other home grown solution. At the Hungarian translation I work with, we developed the filebrowser module to provide an interface on top of our custom subversion repository a few years ago. The idea behind <a href="http://drupal.org/project/l10n_server">the localization server</a> is to provide a better service for all translation teams without resorting to custom solutions to be set up by all teams themself. (There is nothing in this design which stops people to keep using external custom tools, but I hope we can work toward a better management tool, which would fit all groups).</p> <p>This project is in the works for a considerable amount of time now, in fact Bruno Massa started the initial work as part of his "live translation" movement, which I took over to actually get rid all of us from the above described hassles. The reason to announcing this now is that there was no "meat" to show to you before. Now there are at least some screenshots, which show you how this service might look like. I still heavily work on the translation interface, so I cannot show that to you yet (although I know you would be eager to see it) and I welcome any feedback anyway, so feel free to post your opinions in the comments.</p> <h3>Localization client</h3> <p>There is an old feature request: provide an on-page (in-place) translation editor for Drupal sites. So when you notice translation errors or untranslated strings, you can just click and translate the strings on the same page (AJAX to the rescue), without going to the locale module interface and searching there. <a href="http://drupal.org/project/l10n_client">The localization client project (for Drupal 6.x!)</a> deals with just that. There are new features in Drupal 6.x which make this possible, so I started a proof of concept implementation. Several people suggested that this functionality could be connected with the server, so you can share your translations with the community. This is not yet implemented, so stay tuned. The user interface of this module is also quite bare-bones, needs a nicer solution definitely. I would very much welcome people to help here out, as I would like to concentrate on the server component as part of my SoC.</p> <h3>Cleaning up the language list and plural information</h3> <p>An easy and immediate way you can help me is to <a href="http://groups.drupal.org/node/5216">read my SoC group post</a>, and if your language is questioned for whatever reason (bad looking plural formula, bogus language code, too much language variants and so on), then please comment on the issue there. Also, if your language is not in the list, but you have translations in the Drupal.org CVS repository (or hosted your Drupal translations elsewhere), please also comment.</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/5219#comments Translations Thu, 19 Jul 2007 20:33:22 +0000 Gábor Hojtsy 5219 at http://groups.drupal.org http://groups.drupal.org/node/4971 <p>As Drupal 6 feature freeze is in, and part of my SoC involvement was about making D6 better, now is a perfect time to look back on where I am. I was set out to provide solutions in the following three areas as part of my SoC project: NEW TOOLS FOR DRUPAL USERS, NEW TOOLS FOR TRANSLATION TEAMS and WEB BASED TRANSLATION TEAM SUPPORT. Let's look at the details for each:</p> <blockquote><p> NEW TOOLS FOR DRUPAL USERS<br /> - New packaging scripts for core translations to create a folder structure similar to Drupal core with translation files separated per functionality<br /> - Automatic translation import functionality for Drupal to import these files only when needed, without further user intervention<br /> - Batch processing of multiple translation imports </p></blockquote> <p>Apart from packaging scripts (which was imagined to be in project module), most of the desired core improvements are in Drupal 6. The important changes I implemented and got included in Drupal 6 as part of SoC:</p> <ul> <li>install profiles, modules and themes could have a 'translations' subdirectory, where PO files are located</li> <li>install profiles use their PO files to display the installer interface in the available (selected) language</li> <li>the installer imports all PO files for all modules and themes enabled by the profile</li> <li>modules get their PO files imported for all the enabled languages, when a new module gets <em>installed</em></li> <li>themes get their PO files imported for all the enabled languages, when a theme gets <em>enabled</em></li> <li>when you add a new language, all enabled module and enabled theme PO files are imported for the new language</li> </ul> <p>So much for automation :) Unfortunately we cannot remove translations when a module or theme is disabled, due to how the locale data is stored (we don't know whether a string is shared by multiple modules, or what module uses it at all). We remove all translations of course if you remove a language altogether. Yched implemented the batch processing with myself being in close cooperation, so now the update system also work with the batch API.</p> <p>There were some performance and code cleanup improvements in locale module too. One very important improvement I devised and got comitted is the ability to collect the exact list of interface strings used on a page. This (among other things) allows a contributed module to build a JSON array of strings and provide a simple in-place translation function to translate parts of the interface on the fly, while viewing the page. There is no such contributed module yet.</p> <p>(There were lots of other language improvements in Drupal 6 of which I was part of, but those are not strictly related to my SoC project).</p> <p>The other two big topics were:</p> <blockquote><p> NEW TOOLS FOR TRANSLATION TEAMS<br /> - Decouple translations from module and theme projects (implement CVS move scripts, automatically create new projects)<br /> - Relate translation projects to module and theme projects (as well as the Drupal core project itself)<br /> - Monitor and display translation status of the Gettext files used<br /> - Improve packaging scripts to allow compound downloads of projects and related translations<br /> - Provide a service to automatically generate translation templates, so development project owners would not need to even think about translation team support, it would be automatic</p> <p>POSSIBLY: WEB BASED TRANSLATION TEAM SUPPORT (if time permits)<br /> - Web based translation tool.<br /> - Import/export for familiar tools for experts. </p></blockquote> <p>After lengthy discussions with my mentors (see my earlier big post for a sample of that), checking with reality and also with Dries, it turned out that we are better off with forgetting CVS as a backend for translation teams. Decoupling the PO files from contributed modules and themes is important, because otherwise the translations are always out of date, releases are not coordinated, templates are not generated properly, and so on. But solving that with putting the CVS <em>and</em> drupal.org project management burden on translators would skyrocket the complexity and barrier-to-entry for translators.</p> <p>Luckily the web base translation team tool points to another direction, so we looked into possibly providing a web based editor on top of CVS branches, tags, releases and drupal.org projects. That theorized possibility turned out to be a possibly huge mess, so my SoC project was repurposed to the following points:</p> <blockquote><p> IMPLEMENT WEB BASED TRANSLATION TEAM SUPPORT<br /> - Web based translation tool with organic groups<br /> - Automatically parse core and contrib projects for translatable strings<br /> - Relate translations to projects, their releases, the releases files, and the files lines<br /> - Monitor and display translation progress status<br /> - Import/export possibility for translation files and templates<br /> - Packaging solutions for core and contrib project translations </p></blockquote> <p>This new focus covers all the "end goals" set out earlier, but solves them with a web based tool, not a CVS and project+release based backend to reduce the barrier of entry and programatically support sharing between different project translations.</p> <p>Interestingly Bruno Massa started some preliminary work on a poof-of-concept tool, which solved a small set of these goals, way before my Summer of Code project even started. When I described the above grand plans to him, he handed over the existing modules to me, so the now l10n_server and l10n_community modules are aiming to solve the above problems (but more modules could possibly appear as part of the abstraction process).</p> <p>To make the above work well, reusing existing code, I needed a "string extraction API". The potx project which grew out of the old extractor.php script was not up to the task, so I spent a great deal of time refactoring the code, which resulted in a reusable strings extraction API. To be able to import and export gettext data from non-locale module tables, the core locale API also needed to be modified. As the l10n_* modules are developed with Drupal 5, it was not an option on that version, but looking further, I tried to implement a "gettext API" for Drupal 6 in core. Unfortunately feature freeze craze was close at that time, so only the export API was finished and comitted, the import code is not reusable still to be able to parse PO files independently of locale module processes. That said, a lightweight gettext API will be needed in the l10n_* projects.</p> <p>After building up the API groundwork, my focus shifted to drupal.org integration questions. I am in heavy talks with Derek Wright about how the l10n_* modules could get information about projects and releases from drupal.org. Unfortunately the current XML based interfaces are not immediate fits, so we are discussing alternate solution possibilities.</p> <p>I'd be interested in how the project metrics SoC project is going, as our locale data will be a valuable metric to look at, so we can collaborate on integrating the two data sources somehow.</p> <p>The biggest challenge as it seems so far is packaging integration with drupal.org. "Unfortunately" (from this point of view) once a module/theme comes out with a release, it should have an untouched tarball with the code and associated files. Because projects modify their interfaces until the last commits, translations happen to be ready after the release. This makes it impossible to package translations right into the release tarball (this is one of the strong reasons to decouple translations in the first place). But packaging translations per project per language for download would be rather confusing and inconvenient to handle on the user (who downloads a project release, and needs translations for it). Technically, packaging will not be a problem. What seems to be tricky to figure out is <em>how to make it simple</em> for people downloading translations.</p> <p>Currently I am working on "input integration" with the drupal.org project infrastructure, so we get the projects, releases, files and lines for strings. Then I plan to shift focus to making the collaborative translation interface much better (at that time with input from the translators), and finally, the packaging questions will need to be tackled.</p> <p>If everything goes well, the resulting modules will run somewhere on drupal.org (possibly a subsite), and translators will forget that they ever needed to deal with complicated CVS things...</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/4971#comments SoC 2007 Translations Tue, 03 Jul 2007 23:04:47 +0000 Gábor Hojtsy 4971 at http://groups.drupal.org http://groups.drupal.org/node/4531 <p>So one part of my Google Summer of Code project is coming along nicely. Although I have posted a summary to my mentors recently, and we started to discuss some issues, they seem to be overwhelmed with work, so maybe opening up and widening the discussion is appropriate here. I had a hard time deciding whether post here or on the relevant issue (<a href="http://drupal.org/node/105986" title="http://drupal.org/node/105986">http://drupal.org/node/105986</a> is connected to the topic at hand), but I figured I will post a note there to this post, as this gets too long and looks into lots of directions to fit into that issue (not to make that issue a monster discussion).</p> <ol> <li>What's in Drupal 6 already?</li> </ol> <p>I worked a lot to get automatic interface translation imports into Drupal 6. Thankfully Yched contributed the batch API, which made it a lot easier to import multiple interface translations in successive HTTP requests. Then Jakub Suchy helped a lot with testing, so we have automatic interface translation import in Drupal core for modules, install profiles and themes. The development version searches for these in the 'po' subdirectory of the module (or install profile or theme) at hand, but Konstantin Käfer suggested that we should call it 'translations', so that will be the final name.</p> <p>TODO:<br /> - implement an update path (I have good, yet untalked of ideas for this, but it would be offtopic here)<br /> - define a place to put a site specific PO file to, so we can import it when doing a cleanup<br /> - also working on in-place translation enabling Drupal! see: <a href="http://drupal.hu/english/node/18" title="http://drupal.hu/english/node/18">http://drupal.hu/english/node/18</a></p> <ol> <li>What needs to be changed with Drupal.org?</li> </ol> <p>A lot. If you read up on the issue (<a href="http://drupal.org/node/105986" title="http://drupal.org/node/105986">http://drupal.org/node/105986</a>), you will see that having translations separated completely from projects (modules, themes, install profiles) is a good thing, as we can control permissions more granularly, maintain releases with more control, get instant updates on CVS commits, make it possible to file issues against individual translations and so on. As it stands now, we will keep the "language rooted CVS tree", so that the language code will serve as a key for all the translations.</p> <div class="codeblock"><code>translations/<br />..de/<br />..hu/<br />..it/<br />..templates/<br />..tr/</code></div> <p>'drupal-pot' should definitely be changed to 'templates', otherwise noone would understand it. So we have a root with templates and translations. Now what we have now there are a list of files for the Drupal core translation. Moving all project translations here, we would need a more granular structure:</p> <div class="codeblock"><code>translations/<br />..hu/<br />....drupal/<br />....modules/<br />....themes/<br />....profiles/<br />..templates/<br />....drupal/<br />....modules/<br />....themes/<br />....profiles/</code></div> <p>And then you think it is going to be easy, so we can just copy over the core templates to 'templates/drupal' and copy over the core translations to 'hu/drupal'. Well, I don't think so.</p> <p>'Unfortunately' Drupal 6 has this cool new feature, so it can import smaller files for only the modules you actually use. That is a cool performance improvement as well as a usability one. If you have untranslated strings, you know those are from the modules you use, not some unrelated stuff which was just imported because all the translations were merged together. We can try to flatten that structure, and it is even possible for core files to be sorted out into the complex folder structure of modules and themes with their individual translations, but we would not do that for contributed modules for sure. But those can also offer a module set with subfolders and a hierarchical structure within. So what we need:</p> <div class="codeblock"><code>translations/<br />..hu/<br />....drupal/<br />......modules/<br />........aggregator/<br />..........aggregator-module.po<br />........system/<br />..........general.po<br />....modules/<br />......ecommerce/<br />........address/<br />..........address-module.po<br />..templates/<br />....drupal/<br />......modules/<br />........aggregator/<br />..........aggregator-module.pot<br />........system/<br />..........general.pot<br />....modules/<br />......ecommerce/<br />........address/<br />..........address-module.pot</code></div> <p>You get the idea. This gets complex! We need to mirror the whole hierarchy of the projects we support translations for, so that we can effectively package the translations to the right places in the output (and also avoid clashing file names). Note that I did not have hu.po files in all the folders there. It would not make sense! I could have multiple files in the same directory, so I need to distinguish by the name of what is being translated not with the language code.</p> <p>This is all possible to joggle around in CVS, so we can move the existing files around and keep history for existing files still. The bigger questions are how to support the translation workflow later on. There are two fundamental problems: (a) creating translation templates in considered hard, project developers don't do it (b) maintaining translations in CVS / with gettext is considered hard.</p> <p>A: automated translation template generation</p> <p>We really need to generate translation templates automatically. As far as I see, it could even be possible to do it in an oncommit hook, but if that is deemed too resource intensive, we can do it with cron <em>very often</em>, maintaining a FIFO list to organize project branches/tags to generate new templates for. The tricky part here is that we would need to create branches and tags automatically as we discover the need for them, as well as the templates themselfs. So we would need a dedicated CVS user for this script, which is accepted to modify files and add/remove branches/tags on the repository. This does not sound easy. (The other alternative is to let the developers do all this themselfs, but you bet they would not, the translation files are very far away from their work in this setting).</p> <p>B: maintaining a translation is hard</p> <p>Such is life. It seems that Bruno Massa took the helm and started on what was part of my SoC project (the last point which said 'if time permits'). Look: <a href="http://drupal.org/project/lt_server" title="http://drupal.org/project/lt_server">http://drupal.org/project/lt_server</a> and <a href="http://drupal.org/project/live_translation" title="http://drupal.org/project/live_translation">http://drupal.org/project/live_translation</a> He did not even consider supporting branches and tags yet! There is no support for those! He is also not trying to work with existing stuff, copied and modified the potx module for himself, admitted he has no idea how plural formulas work and so on.</p> <p>Anyway, if a completely web based approach could work, we would not need any of the above file based trickery, would still be able to generate files for distribution in the packages (rather then importing them live which is IMHO not suitable for any serious site, does not work when you are offline and so on). BUT! And there is of course a but! We would need to reimplement branching and tagging as well as permission controls for editing translations in Drupal itself. It would not be possible to check out a copy of the translations from CVS, but templates would still need to be generated, see point A.</p> <p>Why Bruno is going fast forward is because he copies existing code instead of playing nice with it and adapting to his needs, (he even came up with a custom XML distribution format for translations instead of reusing the existing PO parser code) AND he does not deal with template generation, branching, permissions and packaging.</p> <p>Which road to go?</p> <p>So where we are really? I had three main objectives for the summer: (a) make Drupal 6 handle translations better, which is nicely shaping, (b) reorganize the CVS repository and projects to support project management better, (c) look into building a web based translation editor if (a) and (b) is already done. Unfortunately (b) and (c) have conflicting requirements. Now translators don't deal with project nodes, release nodes and branching/tagging. Point (b) tosses that job on them in the hopes that it gives them more features and control. But it gives them a lot more project management overhead and even steeper learning curve, more tools to learn to master. Point (c) on the other hand requires rewriting most of the features we wish to get from CVS in Drupal. So two theoretical options:</p> <p>Option one: hide CVS tasks from translators</p> <p>We would need a trusted CVS user again, or need to be able to log in the translators from a web interface through to the CVS repository, so web based simple options can be provided to branch and tag stuff when needed. Branches and tags should be coordinated with the core or contributed project in question in the web app. We need to core around a lot of CVS options and commands here, so we can revert branches if need be and so on.</p> <p>Option two: go all web based</p> <p>Instead of matching CVS branches and tags, we have the project and release nodes to match translations to. If we don't have translations in CVS, we don't need the CVS mangling, but need to relate the actual translations to the nodes on drupal.org. We would throw out lots of CVS power on the window, but gain more translators.</p> <p>Tough questions! Help me by providing tips, ideas, criticism!</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/4531#comments SoC 2007 Translations Tue, 12 Jun 2007 22:43:50 +0000 Gábor Hojtsy 4531 at http://groups.drupal.org http://groups.drupal.org/node/4494 <p>See <a href="http://blog.worldwidelexicon.org/2007/05/25/simple-localization-system-sls/" title="http://blog.worldwidelexicon.org/2007/05/25/simple-localization-system-sls/">http://blog.worldwidelexicon.org/2007/05/25/simple-localization-system-s...</a></p> <blockquote><p> SLS is, as it suggests, a simple way to localize applications and websites. The system works as follows, and is easy to implement in a wide range of scenarios. Let’s imagine that you have a web user interface that you want to make available in many languages. With SLS, you simply do the following. </p></blockquote> <p>This will be demo'd at FooCamp (which Dries is also likely attending), and apparently there will be a Wordpress plugin soon. I have been thinking about a generalized translation hub, so this is of high interest to me. I'd like to have folks here read through and see what this means to Drupal.</p> <p>Can Drupal act as an SLS server? (I think yes). Can it act as an SLS client? (yes!)</p> <p>This really is in line with my thoughts about running t.drupal.org to help in doing distributed translation of Drupal...</p> <div class="og_rss_groups"><a href="/translations">Translations</a></div> http://groups.drupal.org/node/4494#comments Simple Localization System SLS Internationalization Translations Mon, 11 Jun 2007 05:44:32 +0000 Boris Mann 4494 at http://groups.drupal.org http://groups.drupal.org/node/4258 <p>Guys,</p> <p>Im developing a module called <a href="http://drupal.org/project/live_translation">Live Translation</a>. Its divided in three submodules:</p> <ul> <li>Live Translation: all end users will update all strings automatically. no more po/pot files.</li> <li>LT Extractor: similar to POTX &gt; extract all translatable strings from all projects that your site hosts. It also provides a dynamic XML with updates, so users can download it.</li> <li>LT WebTranslation: provides a online interface to all users translate all strings. It uses OG to manage who can translate, sho can create a suggestion and who cannot help.</li> </ul> <p>I real