Bug 12447

Summary: Bulgarian translation
Product: xkeyboard-config Reporter: Alexander Shopov <ash>
Component: GeneralAssignee: xkb
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: medium CC: bensberg
Version: unspecifiedKeywords: i18n
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: gzipped bulgarian translation

Description Alexander Shopov 2007-09-16 12:11:36 UTC
I am attaching the Bulgarian translation gzipped
Comment 1 Alexander Shopov 2007-09-16 12:14:00 UTC
Created attachment 11592 [details]
gzipped bulgarian translation

Please notify me on commit via email or bugzilla
Comment 2 Sergey V. Udaltsov 2007-09-16 14:14:20 UTC
As TP maintainer advised me, I am closing this one as WONTFIX. Pretty please, submit your translation through the TP project. I would not like to create a mess of .po files... No offense meant.
Comment 3 Alexander Shopov 2007-09-17 14:45:53 UTC
Dear guys,

Why do you inflict this world of unbearable pain on me? Why do you insist on me being miserable and frustrated?

Why, oh why do you want to impale me onto the TP robot? Has the world suffering ended and you need a subject to show to psychiatry medical students what happens when you continuously pour sulphuric acid into a lonely translation enthusiast?

I might have suspected ulterior motives in your decisions and might have accepted that you are part of the giant conspiracy of the military industrial complex, had not the TP robot inflicted similar pain onto you.

Why, oh why on Earth do you insist on me using the TP robot? It is a wasteful, unpleasant and error-prone workflow to use. 

I am well aware of its existence - I am the coordinator of the Bulgarian team. It is being coordinator that converted my initial frustration to passionate hatred. When I have to explain the details of the nitpick fascist that TPR is my nerves shatter and I cry in desperation.

I might hurt feelings, but it is not joy or pride that makes me write this letter - but desperation and anxiety.

It is, you know, like we are all sinners past redemption and death and finally boiling to eternity in hell's crucible's TPR when I find the purgatory of Bugzilla, so I can escape this excruciating experience, but you insist on me boiling further on until hell freezes over and you push me deeper and deeper in these soul-melting blazes.

Please, do not do this - I do not deserve such a harsh punishment. Not that I am ideal - I do have my faults, but overall I shave more or less regularly, brush teeth and all - doing chores you know. I am quite a nice, cheerful and lighthearted bloke. Not so when using the TP.

OK. Now - why I consider the TPR workflow simply wrong.

1.  It creates a barrier between translators and developers. We have so much bureaucracy in life, do we really need another in electronic one? Oh, we sing the body electric, and a body electric needs bureaucracy electric.

2.  Having the po-file is simply not enough - you have to check your translation.

  *  In programs like glade based ones you cannot simply compile the po-file and place it a directory and magically have it work. There are xml files that should be remerged.

  *  In programs like gcc, glibc, bash - you have to continuously consult the source - a lonely po-file does nothing.

  *  Sometimes you have to check that your po-file remerged does not cause the compilation and installation of your program to fail.
TP does not solve these problems

3.  You have no notion of the release schedule of the program you are translating.

4.  You burden the developer to specially prepare pot files and then distribute them - and developers simply do not always do that.

5. Even if they do - their normal work causes those files to diverge from the current state of the source control. And in the past I have submitted translations with magically oboleted strings, to magically reappear on update from the developers. But magic simply does not always work and I am short of mana.

6. The TPR workflow creates delays in the work of a translator - this makes it burdensome to rely on it.

7. As I really suspect that other teams are also exasperated and fighting the robot - their translations are also lagging and I cannot use them to check things.

8. If a user finds a problem with the translation - the normal place to propose a bug report and even patch will be bug tracking system. I am providing really niiiiiice and biiiiig patches - why do you want to punish me and not reward me?

9. TPR insistence of some things is silly and sometimes downright wrong. When I translate - I update-merge-compile-test it several times. Dates of generation will naturally be after the date of modification - because I reformat it the standard way, check errors - what is wrong with testing, why should it be discriminated against?

10. Work by email is asynchronous - for this work it is stressful, because with the unreliable email setup we sometimes have, I have no notion of when my work will be accepted. I have no notion when it will be committed.

I suppose it is acceptable to have TP as a way of doing things. I might consider it bad, wasteful and stressful, but some might consider it OK. That will be the uninitiated souls. But when we have other and nicer tools - why use the stone age one? Or do you extract joy when we all do exactly one and the same thing and no breaking out of the Matrix is possible?

Please reconsider your opinion - there are ways of cooperation when we both are not unhappy. Human interaction can be fun, you know. Just mentioning it if TPR has made you forget that.

I throw myself at your kind mercy. It is you with your commit access that will finally decide my fate.

Still - if you do translation for your project, consider committing them through the TPR, not through the usual commit to source control path, so that you can feel that unbearable agony of TPR.

I am just a guy that tries to cooperate and translate. Yeah, I am a TP coordinator - but please do not hold that against me.

Please help me escape the Matrix.

Kind regards:
Comment 4 Sergey V. Udaltsov 2007-09-17 16:06:09 UTC

Your passion really touched my heart. The only reasonable solution I see is declaring Bulgarian translation as "external" and asking TP to forget about Bulgarian language altogether. Do you think this is reasonable? Would you (or some your friends) would continue supporting the project in foreseable future? What I realy do not want to do is submitting your .po files into TP myself, just for the sake of workflow.

Yes, TP is not an ideal workflow. But it guarantees some level of manageability and accountability. Since freedesktop.org does not have its own translation service (like GTP), I am grateful to TP people for the support they provide and would like to play nice with them and follow the rule they set (especially when it also makes my life simple, as a side effect).

So, what would be your view on declaring Bulgarian as "external"?
Comment 5 Benno Schulenberg 2007-09-18 14:39:42 UTC
I've uploaded the file to the robot myself, after fixing three small errors in the header.  Please don't post PO files in bugzilla again -- taking it out of here took five minutes this afternoon, and to make this remark now I've had to wait for two hours for Bugzilla to respond.

That you are TP team leader I do hold, mildly, against you, Alexander.  Instead of venting here, you should have mailed your complaints to the coordinators at the TP.  The robot is, after all, just a program: it can be changed, it can be fixed.  Do you wish to see the diff between the robot four months ago and the robot now?  It is 1756 lines.  (Sure, mostly cosmetic, but there are some real improvements and fixes in there.)  Also, I think you're blaming the robot for something that is caused by your own unusual way of working: you recreate the POT file after having completed the translation.  Almost no other translator does that.  Is it too much to ask from you to leave the POT-Creation-Date as it is given in the latest POT file at the TP intact?  Even if it is, you can easily work around it, by stamping the file after completion with the following function, which I use myself:

msgnow ()
    NEWFIELD="PO-Revision-Date: $(date +"%F %R%z")";
    sed -i "s/^\"PO-Revision-Date:.*\"$/\"$NEWFIELD\\\n\"/" $@

Sergey, if you really want to make your life easier, then drop all PO files from CVS, just like 'tar' has done.  Right before a release you do a simple:

  rsync -Lrtvz translationproject.org::tp/latest/xkeyboard-config/  po

and done.  If you make this part of 'make dist', you don't have to handle PO files ever again, and just point any new translators to the TP.
Comment 6 Sergey V. Udaltsov 2007-09-18 15:09:37 UTC
Benno, thanks for your idea. I think I will do the rsync thing - but only after 1.1 release.

But I am still not sure about status of Bulgarian translations for a future. Will they be handled through TP or Alexander insists on having it externalized and reopening that bug before every release? I am open to any reasonable suggestions, lads - I just want some peace of mind, if you catch my drift...
Comment 7 Benno Schulenberg 2007-09-18 16:12:53 UTC
Sergey, comparing CVS with http://translationproject.org/latest/xkeyboard-config/ it appears that bg.po, fi.po, nl.po, sv.po, uk.po, and vi.po have more recent versions at the TP.  You were probably planning to pull these down just before release, so I'm just telling what i see.

About the Bulgarian translations, we'll have to wait for Alexander's answer.
I've offered to upload the file for him also in the future, if he is willing to format it correctly.  He will not have to deal with the robot then; it will be just me who will be picky.  :)
Comment 8 Benno Schulenberg 2007-09-28 14:54:44 UTC
Closing this as fixed as the file is in CVS now, and Alexander is not responding.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.