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

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



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 redhat com> napisali ste:

Dimitris Glezos (dimitris 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 redhat com
https://www.redhat.com/mailman/listinfo/fedora-trans-list




--
Best regards,
Renato Pavicic

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

Official Opera translator for Croatian language since April 2006


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