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 RenatoPS - 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 tosplit 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