You talk to my heart, I am a real fan of XML and derivates of that instead of the somewhat computing unfriendly getText format that .po uses.
I fought a long time for linux ini files to be XML, today it is msg structures everywhere. XLIFF is /as far as I know) just a definition (or restriction if you prefer) on how to use XML for text pairing, so in that essence it is still around. But It might be hard to find offline translators that are easy to use and which accept XML based files ? Having said that I dont see it as a problem, that translators use .po files and the release build uses something else. Only the original should be .po because then notes/headers etc. would be reserved for the translators. If you look across all the apache projects, there seems to be very different ways of localizing, and different file requirements so an Idea could be to say .po is the original and we then write extractor programs to the needed file formats. jan On 11 October 2012 18:32, Alexandro Colorado <[email protected]> wrote: > On 10/11/12, Jürgen Schmidt <[email protected]> wrote: > > On 10/11/12 5:14 PM, jan iversen wrote: > >> From the description it looks a lot better that POedit. I installed > >> poedit > >> because I got a mail from andrea saying so :-) > >> > >> As far as I can see OmegaT is very useful for new translations, however > >> it > >> does not seem to have a feature that can control existing translations. > >> > >> Doing the danish translation, I have come across a couple of words that > >> are > >> today translated differently. So I was looking at a tool that controlled > >> the translation. > >> > >> Anyhow I will try to use OmegaT for translating the help content, which > >> is > >> due this evening. > >> > >> A pootle server has a form of cloud memory, where every translator can > be > >> given rights (read/write) and I think that would do the job. > > > > yes, the problem is that users have to be committer at Apache ;-) It > > always helps if we volunteers start to work offline first and become > > committer over time. Not optimal but working for now and many people > > prefer offline translation anyway. But it could improve the > > collaboration by downloading only a single po file, translate and upload > > it again. > > > > There is a lot of room for improvements and any good idea to improve the > > whole process is welcome. > > > > I would like to see a completely new tooling to get rid of the sdf files > > that we use in the build and use po files directly. One from my > > Oh yes, I remember some format wars on this regard, what ever happened > to XLIFF, wouldnt this be 'easier' since is XML-to-XML formating as > opposed of POT (plain ol text) to XML? > > > perspective unnecessary conversion step could be eliminated this way. > > But there is more work to do here and many tools who extract the strings > > from sdf have to be changed (xcu files, java property files, help files, > > resource files, ...). Real programming work would be necessary and a lot > > of evaluating how exactly the current process works. But Andre has > > already figured out that a lot unnecessary copying is done here during > > the build process and that there is a lot of room for improvements. > > Volunteers are welcome ;-) > > > > Juergen > > > > > >> > >> > >> Jan I. > >> > >> On 11 October 2012 16:42, Alexandro Colorado <[email protected]> wrote: > >> > >>> Well there is the translation memory used in OmegaT which is one of > >>> the most revered programs. PoEdit has some translation memory support. > >>> http://www.omegat.org/en/omegat.html > >>> > >>> I wonder if there is a way of having a cloud translation memory that > >>> can be shared and used between the whole team. That will allow > >>> translators to get their terminology on the same vein. > >>> > >>> This could be done maybe even if there were cloud po editors. Pootle > >>> editor does use some TM, but is also pretty poorly implemented. Some > >>> UX improvements could go a long way. > >>> > >>> Other things to keep in mind are nemonics and reserved functions like > >>> Spreadsheet formulas. > >>> > >>> > >>> On 10/11/12, jan iversen <[email protected]> wrote: > >>>> Hi. > >>>> > >>>> I think I have used it back in the days where sun made a PC version of > >>>> unix, if that could be made available it could really enhance quality > >>>> of > >>>> the translation. > >>>> > >>>> I am right now looking into making a small program that checks for > this > >>>> kind of translation mishaps. I have tried POconsistency which is nice, > >>> but > >>>> does not control glossary strongly enough. > >>>> > >>>> The one I worked with, had a lot of languages (at least all the > western > >>>> ones). > >>>> > >>>> rgds > >>>> Jan I > >>>> > >>>> On 11 October 2012 15:54, Alexandro Colorado <[email protected]> wrote: > >>>> > >>>>> Back in the Sun days we used to have a Glossary that spread > throughout > >>>>> all products explaining the terminology on different language. It was > >>>>> like an OpenGrok for terms. > >>>>> > >>>>> Also a style guide, which I guess we still do, is only a matter of > >>>>> making available to translators. > >>>>> > >>>>> On 10/11/12, jan iversen <[email protected]> wrote: > >>>>>> HI. > >>>>>> > >>>>>> I would be a good idea to have a glossary.po file for each language, > >>>>>> even > >>>>>> though the program does not use it. It is important that the > >>>>>> translations > >>>>>> are consistent (e.g. edit is translated identically throughout all > >>>>> files). > >>>>>> > >>>>>> I would also like to have a consistency check, that automatically > >>>>>> checks > >>>>>> accelerators and words are translated identically. I have been > >>>>>> playing > >>>>> with > >>>>>> poconsistency which does quite a nice work. > >>>>>> > >>>>>> The idea of having spreadsheets to control sorting etc. is brillant. > >>>>>> I > >>>>> used > >>>>>> to have documents as well to check the functionality of the > >>> dictionary. > >>>>>> > >>>>>> have a nice day > >>>>>> rgds > >>>>>> Jan > >>>>>> > >>>>>> On 10 October 2012 23:57, Rob Weir <[email protected]> wrote: > >>>>>> > >>>>>>> Does this make sense as a general list of tasks for fully > localizing > >>>>>>> OpenOffice for a language? > >>>>>>> > >>>>>>> 1. Translate UI strings in Pootle > >>>>>>> > >>>>>>> 2. Verify translations in a snapshot build of OpenOffice > >>>>>>> > >>>>>>> 3. Verify bundling of correct dictionaries > >>>>>>> > >>>>>>> 4. Verify other areas of localization: sorting, number formatting, > >>>>>>> date formatting, string comparisons. Anything else? Should we > >>>>>>> have > >>>>>>> some standard test spreadsheets and other documents to help verify > >>>>>>> these areas? > >>>>>>> > >>>>>>> 5. Translate help strings. > >>>>>>> > >>>>>>> 6. Help update/maintain native language website, e.g., > >>>>>>> www.openoffice.org/de, etc. > >>>>>>> > >>>>>>> 7. Help translate release announcements, release notes and other > >>>>>>> materials that help promote the new release > >>>>>>> > >>>>>>> Any thing else? > >>>>>>> > >>>>>>> Some languages do only 1-4, which is probably the minimum that will > >>>>>>> give a good user experience. Some languages are enabled for 5-7 as > >>>>>>> well. In areas where we have multiple volunteers this might be one > >>>>>>> way of splitting up the effort. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> -Rob > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Jan Iversen > >>>>>> ________________________________________________ > >>>>>> Tel. no. +34 622 87 66 19 > >>>>>> jandorte.wordpress.com > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Alexandro Colorado > >>>>> PPMC Apache OpenOffice > >>>>> http://es.openoffice.org > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Jan Iversen > >>>> ________________________________________________ > >>>> Tel. no. +34 622 87 66 19 > >>>> jandorte.wordpress.com > >>>> > >>> > >>> > >>> -- > >>> Alexandro Colorado > >>> PPMC Apache OpenOffice > >>> http://es.openoffice.org > >>> > >> > >> > >> > > > > > > > -- > Alexandro Colorado > PPMC Apache OpenOffice > http://es.openoffice.org > -- Jan Iversen ________________________________________________ Tel. no. +34 622 87 66 19 jandorte.wordpress.com
