<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
- Today adding a new section (any id) likely breaks translations
- Many tools exist for editing po files
- Many tools offer statistics for po files
- I presume it's easier to do things like:
--- "if file x is 80%+ translated and up to date, build, else show EN"
--- Or, fine tune it further, paragraph by paragraph (wise? weird?)
- 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.
- 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
