I did it wrong(must "reply to all" and not only "reply"), I send my
answer only to Philip and not to the list, so:
Philip Olson escreveu:
Hello everyone,
As most of us know, we have many outdated translations... so let's
discuss it:
A) Critically old files:
Many translations contain critically old files that should be either
updated or offline. Some ideas that deal with these are:
- Have the build system either not build/show them, or insert huge
warnings (for users)
- Add revcheck[1] tools that list all critically outdated files (for
translators)
- Better define what it means to be critically old (for all)
This is important. What is current definition? For me is a file with
chamnges in contents(add or remove, not spell and ws) that is not
updated by some time.
B) File ownership:
Translators typically insert maintainer information within each file.
If a translator suddenly becomes inactive, these files essentially
become unmaintained yet remain owned. I don't know the extent of this
problem but can only assume it causes delays. Should we worry about
allowing active translators to update any file... especially for
critically old files? They (some) do anyways but let's make something
official.
This is not a trouble. Because if a translator have time, he can update
the files if the ower is not updating it. So this is not a reason to a
file be outdated
C) Attracting new translators:
Once the new build system is online, the setup required to build/test
the manual will be much easier. From here we'll actively find
additional doc team members, including translators. The new
translators will rejuvenate the doc-{lang} lists so then the old
translators (who still subscribe) will wake up. PHP is kind of a big
deal, we can find volunteers. And in the future "The Tool" will allow
easy patch creation via the online manual.
I am working on a script to act as a cvs client in pure php, current we
can have a simple script to get a php module without the use of cvs,
something easy as:
php getphpdoc
And is not hard to make a script to get all changed files that someone
edited and create a tar package, so this person can easy send by email
what it translated to someone which has a cvs account.
The new build system which let the person see what is changed, without
the wait of some hours to build the manual(current I take more than two
hours to build) will make more simple. But it need some more simple docs
for it! Sometime ago I got it from cvs and I do not know how to use it.
Another thing if possible is a server to build the docs one or more
onces by day(too much?), but one once by day is good. If you can see you
work on internet soon after you did it, you will like and try to do
more. No need to wait months. Example: the portuguese in www.php.net is
from 2007-04-18 and after this Felipe Pena have more than 100 new
translation and more than this in updates. He can see all this changes
in docs.php.net but is not the same thing.
D) Outdated translations:
We have several translations that haven't [really] been updated for
years, and it goes without saying that this is bad for everyone so
let's make a plan. Here's one, let's discuss it:
1. Designate the deadest of the dead as INACTIVE_LANGUAGES via phpweb.
~18 of them. This means they won't show up via the select box at
php.net, nor be selectable via my.php.
We could make a rule for this kind: by example, if a file is outdated by
some time, like 3 months, it is replaced by en, and we can make a rule
for the minimum number of translated file that a translation can be,
when it is bellow this number, it is not show any more.
2. Write each list (doc-{lang}) asking if anyone out there is
listening. If so, discuss the translation.
A big +1
3. Alter the php.net 404 handler to work with missing languages, so
ar/manual/foo.php --> en/manual/foo.php
+1 and maybe a note to tell that the language is not translated because
it is "abandoned"?
4. Implement PhD to build active languages for mirrors rsync. Based on
INACTIVE_LANGUAGES from phpweb/includes/languages.inc.
+1
5. Implement PhD to build all languages, active and inactive, for
docs.php.net.
This will not make people asking why they exist in docs.php.net and are
missing in others? They will think in this as a bug that there is some
error and they translation is missing in all other mirrors?
6. Remove all dead/old/non-phd manuals. For example, kr/manual is from
2004. Currently some translations (even en/ within them) are not being
updated/built.
+1
But we must set one fixed way to build: openjade,xslt or phd and stay
with it
7. Look for new translators, and further discuss the translation process.
Thoughts?
There is something that i did little work on it, and from this work I
can get the docs in a pure php script, that is to make a website to let
someone translate the manual in the web. There is(was?) a portuguese
site that let you do this, but in pure text(without the xml is uselles
for us), but many persons did some work on it, simple because it is easy
and take little time to work, you do not need to install and setup
nothing. By example, let who have a cvs account commit direct from the
web and all others, save the translations in a kind of sandbox, so
someone with a cvs account can review and commit it latter.
Fernando Correa da Conceição
Regards,
Philip
[1] http://doc.php.net/php/revcheck.php
