[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Fwd: Translations: String freezes, CVS converging, Packaging]
- From: Renato Pavičić <repavici globalnet hr>
- To: "Fedora Translation Project List" <fedora-trans-list redhat com>
- Subject: Re: [Fwd: Translations: String freezes, CVS converging, Packaging]
- Date: Wed, 07 Mar 2007 21:50:37 +0100
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
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.
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>
Dimitris Glezos (dimitris glezos com) said:
We have two options: one, to have a big `fedora-langpack.rpm` and the
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
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
5) For every language that's added, it requires modification to the
comps file t add the appropriate metadata so that the right thing
In short, I think it would be a tremendous mistake to go to this
model for Fedora.
Fedora-trans-list mailing list
Fedora-trans-list redhat com
mailto:repavici globalnet hr
also mailto:renato translator-shop org
Official Opera translator for Croatian language since April 2006
[Date Prev][Date Next] [Thread Prev][Thread Next]