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
