[Fwd: Translations: String freezes, CVS converging, Packaging]

[Renato Pavičić]

Hi,

I am no programmer, just a translator. To me, and to others that are not  
very skilled in programming tidbits (ie, end-users), could be very  
problematic to use console commands for which everybody says: Oh, it's so  
simple, you just do:
make -u /dev havenot ifwhen /bla/ungh/more/ -evenmore  
-justtoomuchtoremembere -iwishihavespellcheckhere /driving/me/mad  
-whereisconfigforthisone /crap/i/made/typo/again /too/ashamed/to/ask  
//again// -rathergiveuponthisOS

Example: All the stuff programmers complain about divorcing translation  
 from application? Well, I say, what's the fuss? From MY point of view it's  
not that hard. You see? What is simple for one, could be very complicated  
for other. Current schema is simple one - for programmers.

To me it's kinda complicated to check up on PO files in the way they are  
currently organized (one by one PO file, not to forget one by one POT  
file). I rather check up only my language. To me, the current system is  
waste of space! Separation of languages will save up my space.

Due to current system I have 50 directories that I have to check/commit  
one by one. If I could have one (language only) directory, I could perform  
one check and one commit per session. That is what I call simple.

Also, take a look at the stats page. Anything strange there? Like, total  
line number per team? So, if current schema is simple, how come that total  
line numbers differ so much? I think that page speaks for itself, in other  
words - what excately is simple to whome.
If there are separate lang directories, there would be separate template  
directory, and the lang team could simply compare those two. This way,  
everything is simply... different.

One more thing that is simple from my point of view is notification when  
PO is changed/updated. This option is still not implemented, despite my  
nagging. I receive useless e-mail when PO needs QA, useless because I am  
the one who preformed that particular change. I rather receive  
notification when PO file change is NOT preformed by ME.
Currently, I receive notification only when 100% translated file is  
reduced in number of lines. I wish to receive a notification when 100% or  
non-100% file is updated with new lines, or the line number is the same,  
but the content of the lines has changed. Please.

Also, from my point of view, offering an end-user a direct link (on  
desktop, within application) to lang team is simple. Why should they go  
around and around? 8 of 10 users give up on this point.

Few moths back I started on some other localization. I gave up after few  
weeks because all translations were bind within ONE FILE. I tried to  
convince programmer that splitting translations would be beneficial, but  
he said "it's to complicate". Well, I agree it is on the first run, but  
later on it would simplify localization effort.
I think it's same here. Well, not the same, but considering the number of  
modules, it's very close.

Do it once, do it now, and in the future it will not be necessary to do it  
again - because its already done.


BR
Renato

PS - as I said before, I higly respect programmers, but once you made you  
application available for localization - you have to add some parts  
(translator and non-english user) into account. if you cannot help  
localization, do not expect (well and timely) localizated content. what is  
beneficial per programmer capita, could (over time) became unproductive  
per (Fedora) project.
Why is localization always regarded as so simple, so simple that  
translators (that are not programmers as well) have no word?


Dana Wed, 07 Mar 2007 19:21:42 +0100, Bill Nottingham <notting at redhat.com>  
napisali ste:

> Dimitris Glezos (dimitris at glezos.com) said:
>> We have two options: one, to have a big `fedora-langpack.rpm` and the  
>> other to
>> split it in different languages (`fedora-langpack-de.rpm` etc).
>
> I'll follow up on the devel list at all, but as an application author
> and user, I find this to be a remarkably bad idea.
>
> 1) It divorces the translation from the application, making string
> changes => .po file non-automatic.
>
> 2) It ties all the translated applications together as a whole, making
> it impossible for single applications to be logically extracted for
> other people to pull from, whether it's another distribution or
> another project.
>
> 3) It wastes space for anyone that wants to install a subset of
> the package space.
>
> 4) It ties all the translated applications together as a whole when
> they have disaprate development and update cycles - some tools get
> new upstream versions pushed for earlier releases, and some do not.
> Attempting to track this is going to be more work for the translation
> team.
>
> 5) For every language that's added, it requires modification to the
> comps file t add the appropriate metadata so that the right thing
> happens.
>
> In short, I think it would be a tremendous mistake to go to this
> model for Fedora.
>
> Bill
>
> --
> Fedora-trans-list mailing list
> Fedora-trans-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-trans-list
>



-- 
Best regards,
Renato Pavicic

mailto:repavici at globalnet.hr
also mailto:renato at translator-shop.org
homepage: www.translator-shop.org

Official Opera translator for Croatian language since April 2006