[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: A different view of translation process
From:       Caslav Ilic <chaslav () sezampro ! yu>
Date:       2003-08-21 16:44:20
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> [: Gérard Delafond :]
> There is also a problem : as KDE is improving, fixing many security
> holes, people should be stimulated to migrate to up-to-date KDE versions.

I really think it is not the translation that will be the best stimulant
for users to upgrade.

> It's not the case. Many english stings are fixed during new releases.
> That points out another problem : when these strings are fixed, all the
> translation teams must validate their translation, which was good, and
> that gives some useless job for translators.
> That means that english strings should be a translation like other
> languages. The strings to be translated should be arbitrary strings.

I couldn't agree more, but that is another story... It is hard to make
programers consider translation -- as far as I see, in many places there
haven't been implemented plural forms, sentences are split impossibly,
etc.

> The only way the strings are correctly translated when a stable release
> goes out is to make the translated programs work during beta and RC
> periods.

Yes, the way it is now done, this is the case. But the main point is that
this is not the way it *must* be done. I believe there is no technical
reason for translation having to go out immediately with release. As I
said before, most users of translation will not hurry with upgrading, so
translation could be a month or so late.

> > [: Chusslove Illich :]
> > Yes, and users of todays major distributions (using 3.1.x) will miss
> > all improvements, unless they are keen on upgrading either complete
> > distribution, or KDE itself.
>
> [: Gérard Delafond :]
> No. We already know that KDE 3.1.4 will be the best translation release
> ever in french.

And how about users of e.g. 3.1.1? They will not be able to use 3.1.4
translation, and many distributions will simply skip 3.1.4.

> It's true that people who don't want to break their system, and so keep
> their obsolete 2.2 system, could get benefit of fixes in translations.
> That would need to maintain some branches for all the branches ever out.
> I cannot figure how this could be done.

Ok, this is the main point, and some technical explaining is in order.

First of all, there should no longer be the notion of supporting this or
that branch, but only "special" HEAD branch. Team should make a decision
which releases it will support, based on the ammount of additional work it
must do -- that is, amount of messages specific to previous releases, and
not found in current HEAD templates.

For example, lets say you want to support all releases from 3.1.0 to
current moment (as I said before, this would be 7-9% more work). These
releases are 3.1.0, 3.1.1, 3.1.2, 3.1.3 and HEAD. Based on the code I made
so far, you would do something like this:

$ intrans -m import -c <...>/HEAD/<...>/messages \
                    -p <...>/3.1.3/<...>/messages -r 3.1.3

$ intrans -m import -c <...>/HEAD/<...>/messages \
                    -p <...>/3.1.2/<...>/messages -r 3.1.2

...and so on.

Lets see some messages in <...>/HEAD/<...>/messages/kdelibs/kdelibs.po file
after that first command:

#: rc.cpp:8
msgid "Less <<"
msgstr "Мање <<"

This message is present in current HEAD templates, but not in release 3.1.3

#: rc.cpp:1
#> 3.1.3
msgid "Editor Chooser"
msgstr "Изборник уређивача"

This message is present both in current HEAD templates and in release 3.1.3

#: rc.cpp:52
#, obs
#> 3.1.3
msgid "HTTP headers:"
msgstr "HTTP заглавља:"

This message is present in release 3.1.3, but not in HEAD templates ("#,
obs" comment stands for "obsolete").

#: rc.cpp:61
#, obs
#, dup: ./kdelibs/kdeprint
#> 3.1.x
msgid "&PageMarks"
msgstr "&Маркери страница"

This message is present in release 3.1.3, but not in HEAD templates,
however it is duplicate of same message in <...>/kdelibs/kdeprint.po, so
doesn't need translating (there is automatic update of duplicates mode).
And in <...>/kdelibs/kdeprint.po, there is:

#: rc.cpp:3 rc.cpp:7
#, org: ./kdelibs/kdelibs
msgid "&PageMarks"
msgstr "&Маркери страница"

Here, "#, org:" comment is saying that there is duplicate of this message
in ./kdelibs/kdelibs.

And more combinations...

What you have here is full set of duplicate references and release
tracking. At any point, you can decide what you want to do with
translation. You could, with one command, strip all obsolete messages
prior to some release (if additional work becomes to heavy), or prepare
translation for one chosen release. This is job for one man, and all other
team members would happily translate HEAD files, not worrying about
releases at all (and team memebers can, and should, run different releases
within supported ones).

When you want to upgrade translation to newest templates, you would use:

$ intrans -m upgrade -c <...>/HEAD/<...>/messages \
                     -t <...>/HEAD/<...>/templates

which would produce similar, albeit slightly different effects to import
mode.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/RPbmMSGXgigGr3ERAguRAJ4oq+ZzdSNqSBQr3DsPdFbnYI6jOACgte/b
hmVcgWOIK3WnffEzBaT/UDQ=
=mz8B
-----END PGP SIGNATURE-----



[prev in list] [next in list] [prev in thread] [next in thread]