[l10n-dev] BigEventsOOo2007
Hi, 2007 is gone. Does anyone summarize the important events of OOo in 2007? I want to put the list of BigEventsOOo2007 into website or Wiki of Chinese commnity. Thanks & Regards! --- Cheng Lin 2008-01-04
Re: [l10n-dev] Formats, tools, and workflow
Op Donderdag 2008-01-03 skryf Clytie Siddall: > Friedel, thanks for your detailed reply. > > For now, I want to focus on retaining metadata and a viable update > process, so please excuse my not replying to other parts of your > message. > Of course. As background for uninitiated readers, most of the commands I mention here are programs in the translate toolkit, and not all of these functionalities are provided by the Pootle front-end. They are of course freely available as part of the translate toolkit: http://translate.sourceforge.net/wiki/toolkit/index > On 02/01/2008, at 9:39 PM, F Wolff wrote: > > ... ... > > > > > > We also have a converter that goes directly from SDF to XLIFF. It > > shipped with the current version of the toolkit, although a packaging > > bug might hide it for some users. The packaging bug will be fixed in > > the > > next versions of the toolkit. > > How much metadata storable in XLIFF can the filter transfer to SDF? Very little, and I don't think this is where our effort should be spent. Although I consider the SDF file something I only deliver and never touch, I understand the issues you mention below. > > > > > > gsicheck errors: > > Alessandro, if there are errors reported by gsicheck from the SDF > > files > > created by the translate toolkit and that are not reported by pofilter > > (in Pootle they are listed as "checks"), I would really like to know. > > None has been reported on our list or bugzilla as far as I can > > remember. > > I agree that we should be generating good SDF files after our > > translation process. > > The problem probably is that we use one or the other. I check my PO > files with msgfmt when editing offline, then once I convert to SDF, I > run gischeck (now I actually have gsicheck for OSX). msgfmt is nice, but very limited especially if you are checking OOo translations. It doesn't know about OOo variables or XML tags and properties. As far as I know there is a pofilter test for each of the things that gsicheck checks for (and several others, of course). > > Once our files are back on Pootle, I can give you further feedback on > pofilter. As you know, we still need to work on language-specific or > more inclusive checks (e.g. « guillemets » being used instead of > "quotation marks", spacing being acceptable before question and > exclamation marks with some languages) to reduce the number of false > positives which, for my language at least, is discouragingly high. This has been addressed with infrastructure to customise tests per language. At least the guillemets should not pose any problems, and we can discuss the other requirements. I think I solved the spacing before !? for French and there are now some customisations for several languages (including Vietnamese). > > > > > > Clytie wrote: > >> We would need an upgrade process for strings that somehow retains > >> that > >> metadata on our side. I don't know how we could do that. > > What Javier wrote here is right: we maintain our translations in > > localisation formats. Then all of the information (not only comments, > > but also things like state, last translator, etc.) Converting to SDF > > can therefore be seen as being similar to compiling to binary > > format. We > > store our localisation formats in a version control system, and that > > is > > considered to be the stored translations. This way we also don't > > need to > > "retranslate with a TM" at the start of version update such as the > > method is with OmegaT (according to my understanding). The files are > > just updated with pot2po (which can optionally use a TMX file for > > fuzzy > > matching while upgrading the files) > > If I download the latest GSI file (which is more economical than > grabbing the whole POT tree), then convert it (oo2po) to POT, then > update (pomigrate) my previous PO files to the new POTs, my PO > metadata would remain. (I hope.) > Yes > However, I find it easier to make quick changes in the GSI file, > because it is only one file, which is more viable for global search- > and-replace and checking and updating specific strings. > I understand that. If you don't like the workflow offered by pogrep and pomerge, I understand that editing the SDF file directly is attractive. We'll hopefully work on search and replace in Pootle soon. for reference: http://translate.sourceforge.net/wiki/toolkit/pogrep http://translate.sourceforge.net/wiki/toolkit/pomerge Of course, searching with pogrep has other advantages, like handling accelerators and unicode normalisation. > (It probably wouldn't be more difficult technically to do that over > the entire tree, but for some reason it just seems more complex. And I > don't have much concentration left to work with.) > > So if I update the GSI file, before merging with the new POTs, I have > to convert my GSI file back into PO, because it is now my current > translation. > > And right there, I lose al
Re: [l10n-dev] Formats, tools, and workflow
Friedel, thanks for your detailed reply. For now, I want to focus on retaining metadata and a viable update process, so please excuse my not replying to other parts of your message. On 02/01/2008, at 9:39 PM, F Wolff wrote: ... Yuri, I agree that context is a big issue, and I think we agree that context is mostly an independent issue from the workflow and file formats. As far as I know the SDF file can already contain meta-information by means of the x-comment information. oo2po from the translate toolkit will add those notes to the PO file (and oo2xliff will add it to note tags of XLIFF files). I think the issue is rather that these haven't been maintained. I don't personally know much about this. Perhaps somebody can add some information about SDF files with x- comment information? That would certainly be interesting. We also have a converter that goes directly from SDF to XLIFF. It shipped with the current version of the toolkit, although a packaging bug might hide it for some users. The packaging bug will be fixed in the next versions of the toolkit. How much metadata storable in XLIFF can the filter transfer to SDF? gsicheck errors: Alessandro, if there are errors reported by gsicheck from the SDF files created by the translate toolkit and that are not reported by pofilter (in Pootle they are listed as "checks"), I would really like to know. None has been reported on our list or bugzilla as far as I can remember. I agree that we should be generating good SDF files after our translation process. The problem probably is that we use one or the other. I check my PO files with msgfmt when editing offline, then once I convert to SDF, I run gischeck (now I actually have gsicheck for OSX). Once our files are back on Pootle, I can give you further feedback on pofilter. As you know, we still need to work on language-specific or more inclusive checks (e.g. « guillemets » being used instead of "quotation marks", spacing being acceptable before question and exclamation marks with some languages) to reduce the number of false positives which, for my language at least, is discouragingly high. Clytie wrote: We would need an upgrade process for strings that somehow retains that metadata on our side. I don't know how we could do that. What Javier wrote here is right: we maintain our translations in localisation formats. Then all of the information (not only comments, but also things like state, last translator, etc.) Converting to SDF can therefore be seen as being similar to compiling to binary format. We store our localisation formats in a version control system, and that is considered to be the stored translations. This way we also don't need to "retranslate with a TM" at the start of version update such as the method is with OmegaT (according to my understanding). The files are just updated with pot2po (which can optionally use a TMX file for fuzzy matching while upgrading the files) If I download the latest GSI file (which is more economical than grabbing the whole POT tree), then convert it (oo2po) to POT, then update (pomigrate) my previous PO files to the new POTs, my PO metadata would remain. (I hope.) However, I find it easier to make quick changes in the GSI file, because it is only one file, which is more viable for global search- and-replace and checking and updating specific strings. (It probably wouldn't be more difficult technically to do that over the entire tree, but for some reason it just seems more complex. And I don't have much concentration left to work with.) So if I update the GSI file, before merging with the new POTs, I have to convert my GSI file back into PO, because it is now my current translation. And right there, I lose all my metadata. My PO directory won't have any, because the GSI file doesn't. (Unless there is some way we can merge a GSI with an existing PO tree?) The only way to avoid this is not to work with the GSI file at all. But working with a whole PO tree is a bit clumsy. If Pootle makes the whole conversion, update and submission process invisible to us translators, that would be a great help. But I'm not sure yet that the PO tree, whether online or offline, is a good vehicle for fine-tuning and quick adjustments. As an example, I'm translating a Help PO file, and the Help string quotes an interface string (menu item, preferences etc.). So I go to the GSI file to check the translation of the interface string, to make sure I will use the exact same translation in the Help. Skipping findwise through the GSI file, it is easier to compare similar strings. I sometimes find that identical strings, (which for some peculiar reason occur frequently to be translated again, and yet again in OpenOffice.org) have not been translated identically. It's quicker to check, and fix, that sort of thing in a single file. My PO editor handles similar strings, comp
Re: [l10n-dev] Formats, tools, and workflow
Thanks Friedel for your explanation. F Wolff 쓴 글: > > Glossary matching in Pootle: > Pootle can do glossary matching, but it needs to be configured. My > understanding is that Aijin Kim from Sun will look at this soon. It is > actually quite easy and people should be able to maintain their own > terminology if permissions are configured in that way. > For Glossary matching, we already have 'Terminology' project in the Pootle however no community is currently using it. If community want to work for a specific language on the terminology project, I can configure proper privileges for them. > TM in Pootle > Pootle can do TM matching. The bulk of useful fuzzy matches can already > be provided in the files when they are upgraded to the newer OOo > version. Alternative suggestions can be provided during translation, > although it doesn't work in the same way as offline translation tools. > This also needs to be administered by the server administrator. Details > here: > http://translate.sourceforge.net/wiki/pootle/updatetm > I'm planning to integrate terminology/TM matching feature to OO.o Pootle and have drafted a wiki page: http://wiki.services.openoffice.org/wiki/Pootle_Glossary_Guide I suggest that we discuss the workflow on the mailing list and build a concrete workflow. Regards, Aijin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
