Philip Olson escreveu:
<snip>
With the new editor online why change to po? More work lost and more markup changes? Sorry but each time that en make a change like this is less people on translation, and days of work only to update to a new system. Will be more one system to mantain, more time lose on doc build, phd did a great work on reducing it and making it simple, now increase it again and make a lot more comples again? So: will be a en file, this file is converted to po, i have to see the diffs in en po, do it in pt_BR, convert my file again to xml, build it. If there is a kind of auto update tool like the used for po will break many langs, po is usefull for short messages for text is horrible. At last make a option for everyone who want keeps working direct on xml files and not on pot.

Fernando.

Okay, I'll summarize why I feel a gettext approach is good. If I misunderstand the situation then _please_ say so as I am not an expert on translations. The bottom line is our current system is archaic, broken, and in need of a major overhaul. However, we don't need to rush into anything but I figure using po files would be a good base. So:

- Today a markup change to EN easily breaks translations
The po will resolve this? Will have any kind of autoupdate for each translation ?
- Today adding a new section (any id) likely breaks translations
Same as above?
- Many tools exist for editing po files
Many tools exist for xml files too, and everyone working with php must have some of then

- Many tools offer statistics for po files
And this will make the translations better if we know how many sentences in a file is transtaled or uptodate?
- I presume it's easier to do things like:
--- "if file x is 80%+ translated and up to date, build, else show EN"
There is not parcial translations, and if there is wrong. If the file is not updated some revisions do not build it, is more simple than a parcial translated file or worst, a file with some sentences in both languages

--- Or, fine tune it further, paragraph by paragraph (wise? weird?)
Will do as same as above, a paragraph in each language? The po update will do this because it is done for simple sentences, not for texts

- Translators can focus on translating and not DocBook or markup
--- Ex: As of one minute ago, 5/11 of our 'active' translations are not building. I doubt any of the 20 others do at all.
What markup the translator need to know? Only hot to work with xml without break it, translator do not add tags and do not remove then.

- Better translation tools are available with po files, like for TM and CAT
- Other people use it, so maybe it's the cool thing to do
- Since other people do it, we can steal their tools and ideas

Our current system is not working. We have two translations that can be considered fully "up to date" (JA and FR). And now to summarize reasons why we should not use PO files:

- Longer build time for docs
- Must learn something new
- Must create new tools that help deal with them
- Deal with contextual issues in PO files

A few problems we must solve:

- Most translations are dead or have little life -- yet the global PHP community is huge
- Translators shouldn't have to worry about Markup (DocBook or otherwise)
- Changes/additions to EN shouldn't break translations
- Today we require CVS Revision numbers, which won't exist in SVN (CVS->SVN is coming this month)

Rant: I'm baffled by how little attention the topic of translations receives in the Open Source world. It's treated like an afterthought when really it should be central to everything. All efforts appear as hacks including the use of po files for a manual. This is sad. Or, did I miss the memo? /Rant.

So to reply specifically to Fernando's concerns: Although some markup still exists within translated strings (in the PO files), I figure typically translators building the translation won't be necessary. We could setup a system to do the build and yell at the translations list when it's broken, or something similar, but point is I don't see this as a block for translations. I imagine a translator opening a PO file and translating very fast and not worrying about much else. Also, I don't think having multiple options (XML or PO) for translators is worth the effort.

What do people think? It's now or never. Questions? Suggestions? Other ideas?

Regards,
Philip



Do as you want. But because all that markup and changes like this many peolple have left the pt_BR translation. Was days of work only to make it build with livedocs., more work with phd(this was good) and now the po, more tools, more work, more one thing to setup, more thing to learn === less translators.

Fernando.

Reply via email to