Re: [l10n-dev] TM, glossaries and OmegaT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Helary ha scritto: On 11 juin 07, at 22:07, Rafaella Braconi wrote: Hi Alexandro, for Russian Italian and Khmer we are referring to the Pootle server hosted on the Sun virtuallab. Please see details at: http://wiki.services.openoffice.org/wiki/New_Translation_Process_%28Pootle_server%29 The 3 above languages are the only one which will be using Pootle to translate the 2.3 version since we are in the initial/pilot phase. If everything goes well or at least we sort our the issues and we are able to fix them, all other languages and team that want to be added to this tool are more than welcome to join. That would be for the 2.4 release. If non-pootle users still want to use TMs it is possible to use OmegaT too. Sun can probably provide us with TMX files of previous translations in the relevant language pairs, the SunGloss contents can be exported as a glossary file and the source PO can be pretty much translated as is. The correct procedure would be: 0) create a project in OmegaT 1) correctly format the PO file with msgcat 2) put that file in /source/ 3) make sure that your TMX has srclang set to your source language the way it was defined in the project settings 4) put the TMX file in /tm/ 5) make sure the exported SunGloss is a tab separated list in at most 3 columns (1st col= source language, 2nd col=target lang, 3rd col= comments) 6) put the glossary in /glossary/ 7) open the project and translate 8) when the translation is completed, msgcat the file in /target/ and deliver For info, OmegaT is a GPLed Java Computer Aided Translation tool developed for _translators_. It is specifically _not_ for geeks. Which means that it is relatively straight forward to use. I am pretty sure the filters can be tweaked to directly support the .sdf format but I leave that to others. I know some already use it here. NetBeans localizers also use it intensively. And real translators too :) Jean-Christophe Helary (OOo-fr) I should have thought about that a couple of weeks ago, before going around looking for info on PO editors and all the rest. I think I've missed the point in which OmegaT started supporting PO files... :o( OmegaT is certainly a great tool and it has proven extremely useful for the Italian community in translating OOoAuthors.org documentation. We are now working on the OLH translation with poEdit and most of the translators are complaining about the change: for a translator OmegaT is just way better than any PO editor. I've tried doing what Jean-Cristophe suggested above and seen that it could work. The only issue is that some TM matches will make no sense because OmegaT take the tags into consideration while computing the match percentage. For instance, for the following segment: \\link href=\\\text/shared/01/online_update.xhp\Check for Updates\\/link\\ OmegaT displayed this 60% match: 1) \\link href=\\\text/shared/01/0211.xhp\Navigator for Master Documents\\/link\\ \\link href=\\\text/shared/01/0211.xhp\Navigatore per documenti master\\/link\\ 60% 070108-it-for-mini-tm.tmx As you can see the only common word between the two is the preposition FOR. It doesn't make much sense but it is certainly better than poEdit which displays no TM matches at all, and most of the other matches are indeed useful. I guess it depends on the quality of the TM we are using. I feel that in this case working with a Po editor has one advantage: the extracted strings Sun has provided us contain strings considered new and changed. The changed strings contain the previous translation and work therefore as a sort of TM. Here's an example: msgid \\bookmark_value\\toolbars; Form Navigation bar\\/bookmark_valuebookmark_value\\Navigation bar;forms\\/bookmark_valuebookmark_value\\sorting; data in forms\\/bookmark_valuebookmark_value\\data; sorting in forms\\/bookmark_valuebookmark_value\\forms;sorting data\\/bookmark_value\\ msgstr \\bookmark_value\\Barra dei simboli;barra di navigazione\\/bookmark_valuebookmark_value\\Barra di navigazione;formulari\\/bookmark_valuebookmark_value\\Ordinamento;dati in formulari\\/bookmark_valuebookmark_value\\Dati;ordinamento nei formulari\\/bookmark_valuebookmark_value\\Formulario;ordinamento dei dati\\/bookmark_value\\ If you look at the two carefully and speak a little Italian you can see that the translation does not correspond to the original string as that was changed during the development of OOo, but it is indeed very close. Form Navigation bar is translated as Barra di navigazione whereas it should be Barra di navigazione dei formulari However, when translating the same segment with OmegaT, I get this 96% match from the TM which in fact contain the same text as the msgstr string in the PO file: 1) \\bookmark_value\\toolbars; Navigation bar\\/bookmark_valuebookmark_value\\Navigation
[l10n-dev] Translation Schedule for 2.3 - QA
Dear All, I've updated the wiki with some QA which came along these days http://wiki.services.openoffice.org/wiki/Translation_for_2.3#Q_.26_A Regards, Rafaella Rafaella Braconi wrote: Dear Translators/Localizers, I would like to give you some information about the upcoming 2.3 update release. Translation deadline for 2.3 is July 26th, 2007 We estimate that the wordcount to be translated for the 2.3 update release to be approx. 3000 for the GUI and 17,000 for the Help. Note that July 26th is also the bug fixing deadline for all language relevant issues. After this deadline only very critical l10n bugs will be fixed. Release Map with translation deadlines specific for the 2.3 release can be found at: http://wiki.services.openoffice.org/wiki/OOoRelease23 For this release following languages/teams will be translating using the Pootle Server we recently set up on the virtuallab: Italian, Khmer, Russian The Sun/Globalization team (in a few cases in collaboration with some N-L communities) will be working on the below languages: French, Italian, German, Swedish, Spanish, Brazilian Portuguese, Dutch, Chinese Simplified, Chinese Traditional, Korean, Japanese, Hungarian, Polish However, if you wish to contribute to the translation work for the above listed languages - as some of the native language team did for last release - just drop me an email specifying the volume you will be able to translate by June 4th. The Chinese OOo native language team will be translating the complete update release. In case of collaboration work between Sun and N-L teams, the translation schedule will be: 1st handoff delivery from Sun (for the above languages)- June 5th/6th delivery to Sun: July 5th The volume - based on actual wordcounts (that may vary a bit) is: Help: 15,000 GUI: 3,000 2nd and final handoff: delivery from Sun (for the above langauges): July 12th delivery to Sun: July 26th The volume of this second handoff will be estimated at the beginning of July. The process to follow will be: - Sun creates issues and attaches .sdf files to translate (volume to be decided by each Community based on their availability and resources) - Issues will be assigned to the translation Community leads - Community converts into po files (if any problem with that we will take over conversion) - Community translates the files using a translation .po editor - Community back converts the .po files into .sdf - Community runs gsicheck on sdf and delivers back to Sun - Sun will import the translated files into 2.3 - Sun will carry our linguistic review on translated files - Community will implement linguistic review results into translated files and deliver updated files no later than UI and feature freeze date for 2.4 release. Hope this information is useful for you to schedule your work. Kind Regards, Rafaella - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Deadline for OOo 2.3 translation is July 26th, 2007
Hi all, *** the deadline for providing GSI / SDF files for the OOo 2.3 release is July 26th, 2007 *** As the integration cause a lot of work do not provide sdf files that cover less then 80 % ( UI only ) translation done. Also please add the en-US translation to your sdf file. Important: To prevent confusion and big mess please ensure that your issue has the following properties set: Assign to [EMAIL PROTECTED] , Target milestone to 2.3 , Component l10n , Subcomponent code , Issue type ENHANCEMENT And as usual please: - File an issuezilla bug to [EMAIL PROTECTED] . Please don't attach your file directly to that issue, better provide an URL / link pointing to your file. Only attach if you don't have any webspace available. ( http://qa.openoffice.org/issue_handling/project_issues.html ) - Please take care that the GSI / SDF file format is not violated ( format errors like wrong amount of tabs, shifted columns, ... ). You can use the tool gsicheck to perform basic checks on your file. gsicheck is located in the transex3 module. usage: gsicheck -c -l myfile.sdf - We try to correctly update our database status information which would later help us to improve the overall quality of the translation. Please provide a GSI / SDF file containing both, your language and the corresponding en-US source string. Please note that the en-US string have to be the same milestone like your translation. Cheers, Ivo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] TM, glossaries and OmegaT
Ale, If non-pootle users still want to use TMs it is possible to use OmegaT too. I should have thought about that a couple of weeks ago, before going around looking for info on PO editors and all the rest. I think I've missed the point in which OmegaT started supporting PO files... :o( Sincerely, I really wondered why you werre not considering it when you started asking your questions about PO files here and there :) We are now working on the OLH translation with poEdit and most of the translators are complaining about the change: for a translator OmegaT is just way better than any PO editor. Especially if you work intensively with TMs. I've tried doing what Jean-Cristophe suggested above and seen that it could work. The only issue is that some TM matches will make no sense because OmegaT take the tags into consideration while computing the match percentage. For instance, for the following segment: Ok, the problem is that PO files are not supposed to contain XML strings :) Hence the suggestion that a little tweaking of the existing filters would provide better matches with the original .sdf files. But I've worked with OOo sdf-po converted files in the past and had no problem getting over this issue. I have not yet checked the current files' contents but if it is more about text than links then you'd rather use OmegaT with your TMX files. Given all this, I would say that OmegaT could be the solution here. At least for the Italian community which is used to this tool and appreciate its features. I'm going to give it a try. One of the things we'll have to pay attention to is whether the translated file are correct and can be imported painlessly into Sun database as an .sdf file. I'll send Sun a few translated files to test this and will report back as soon as the check is done. This is my worry also. So you should give it a try first with a short file. One thing is not clear, though: why should I need to run msgcat? Can't I just work with a bunch of separated po files and directories in a tree structure (basically what I get when I run oo2po on the .sdf file)? msgcat was suggested by the original PO file developer. See if that works without it. JC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
