Re: Using Git and separating translations into their own l10n-LL repository



Well, I'm sure the devels are able to make the system work in anyway
they choose, that's why I yell so loudly to get all the po files of
one language into one single directory. Now that would cut down the
maintenance.

If you take a look the translation process, you see, that it consists
of 3 major steps. Acquiring the file(s) to translate, translating and
commiting.

When you "choose" the file, you have to know what is already
translated, what is reserved, proofed ... or under revision. You also
have to have a quick access to pot files. How many clicks you need to
do that? If it's more than one after visiting the page from your
favorite bar, there is something like click/bandwidth/time, that can
be improved, right?

Translation by itself is an individual project and has nothing to do
with the git or svn.

How many times did you "correct" a single word, that was not syncd in
many translations? Last time I did that I had to "repair" 17 files.
Why carry apple by apple from the market if you can take a basket with
you. If you need more than one line in svn/git or one click on the
website more than it's necessary, there is space for improvement,
rignt. Getting the files up and down should mean NO effort. It should
be easier then ftp-ing them to some server. The real work, with all
the logging and diffing, crediting, upgrading and stuff should start
from that point on.

The last maintainer quit being a mantainer, because he had no time.
The last zip that I sent him for 2.22 some time ago had 83 upgraded
files. If someone sends me 83 files to commit, I'd break down and cry
...

Then I'd start again yelling about SINGLE FOLDER for one language.
Less time needed, less bandwidth, less clicks, less nerves, more
translating and proofing. A winning situation.

M!

On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen <k nielsen81 gmail com> wrote:
> 2009/1/19 Matej Urban <matej urban gmail com>:
>> Thanks, Gil,
>>
>> I will wait and see, but since I'm a translator/mantainer and since I
>> doubt I will be able to upload many files at once, the only difference
>> so far I see, is that I will replace keyboard keystrokes for mouse
>> clicks. There will be no changelog, which is an improvement :)
>
> I don't see how this solution will NOT improve your situation. When
> you want to commit you just have to upload a file via a web-interface.
> Which means that you cut both space and bandwitdth down to a minimum,
> the only thing left is time. You do save the time it takes out to
> check out the modules and fill out the ChangeLog, but you do not get
> to save the time you could if you could commit more files at once. But
> in my opinion that should never be made a possibility (and I'm a
> translation coordinator not a developer), you use verision control
> systems (of any kind) to track changes, which makes it easy to revert
> if you do something wrong, but that hardly makes sense if you commit
> very large changes.
>
> Regards Kenneth
>
> PS: I have a commit script I can send you if you want to use it in the
> meantime, but let me know only if you want to use it as I would have
> to nicefy it a bit before ot could be used by others.
>
>>
>> Anyhow, in the end I will use whatever I'll need to do it, but keep
>> nagging about it. For some reason, I really doubt that single dir for
>> all po files, is a big programing deal. No obsolete clicks, no hassle,
>> just pure translation work.
>>
>> Matej
>>
>> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada <gforcada gnome org> wrote:
>>> Hi,
>>>
>>> Actually a lot has changed:
>>>
>>> - for advanced-translators the same workflow will be maintained.
>>> - for plain translators a web interface to commit languages will be
>>> provided.
>>>
>>> So I think you fall in the second option and thus you will need to have
>>> access to http://l10n.gnome.org to download updated po files (like you
>>> can do right know), track its status (like as of January you can do
>>> right now) and commit them in source repositories (like you will be able
>>> to do in a not-so-distant-future, Claude said it has a beta working
>>> version that does this, I'm right Claude?)
>>>
>>> So, all in all, your workflow will be a lot improved since you will only
>>> have to download and upload files from/to http://l10n.gnome.org :)
>>>
>>> Hope I haven't said any lie!
>>>
>>> Cheers,
>>>
>>> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure:
>>>> Hello,
>>>>
>>>> I'm really trying to understand the changes. The title sais:
>>>> Using Git and separating translations into their own l10n-LL repository
>>>>
>>>> The title implies that ALL and ONLY po files from ALL the languages UI
>>>> and HELP will fall into "l10n-LL" repository, but that will not be the
>>>> case, as I understand. I really don't know why this is so unpopular
>>>> among developers.
>>>>
>>>> I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and
>>>> also a reminder that I don't fill-in the changelog entries. I can not
>>>> find those great "scripts" in the gnome archive, that will do all the
>>>> work in my place, nor can I write one, so doing it step by step is the
>>>> only way I know. It takes TOO much time, TOO much bandwidth and TOO
>>>> much space to maintain the language. Putting/linking/sync all po files
>>>> in one single dir solves many problems for coords like myself.
>>>>
>>>> Please, guys, check again if there is a way to do that. Last
>>>> coordinator dropped out of the translation game because this updating
>>>> took too much of everything, especially his time.
>>>>
>>>> Matej
>>> --
>>> gil forcada
>>>
>>> [ca] guifi.net - una xarxa lliure que no para de créixer
>>> [en] guifi.net - a non-stopping free network
>>> bloc: http://gil.badall.net
>>>
>>>
>> _______________________________________________
>> gnome-i18n mailing list
>> gnome-i18n gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]