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.