Thanks. The biggest problem with .po is that it does not contain a file reference (the directory structure is a copy of the source structure), I can put the path in the po file as a comment, but that is not very robust.
The translators will see no difference (apart from changing poEdit for offline), so their barrier is the same. Seen purely from a development perspective the time needed is about the same. I dont know if it is a valid point, but with xliff we get automatic support for the status of the translation (to be done, to be reviewed, translated, integrated...) which might be something we should use in the future (NOT as a first step). I have no opinion on 1 or 2 projects, that was in the old document...logistically it is easier with just one project. However it is easy to make 1 UI and 1 HELP file, but making like 20 might be more difficult (which sources go where..). thanks for your input. jan On 17 October 2012 10:06, Andrea Pescetti <pesce...@apache.org> wrote: > On 16/10/2012 jan iversen wrote: > >> Finally I have finished describing the current process, and also combining >> all the notes on open issues I could find. >> Please have a look at: >> http://wiki.openoffice.org/**wiki/File:L10proc.pdf<http://wiki.openoffice.org/wiki/File:L10proc.pdf> >> and >> http://wiki.openoffice.org/**wiki/Localization_AOO<http://wiki.openoffice.org/wiki/Localization_AOO> >> > > Thanks, this is a great contribution. A few quick comments on the contents: > > - It's good to reduce the number of files. Keep in mind, though, that in > bigger teams the most convenient way to split work is by working on > separate files. If we manage to have about 20 files total this should be OK > for all teams. > > - I wouldn't create UI and Help as two Pootle projects: it's very > important that UI and Help translations are consistent. I understand, > though, that some team will only translate the UI, so maybe it would be > possible to have two different projects, so long as a volunteer can decide > to work on Calc and easily identify Calc-relevant new strings in both > projects. > > - PO vs XLIFF is a very old discussion... PO is simple and text-based. It > has limitations but it's very easy to work with, and in this phase I would > privilege a low entry barrier. > > Regards, > Andrea. >
