Jeroen Ruigrok van der Werven wrote: > [Finally got Internet again.] > > -On [20080513 19:55], Christian Boos ([EMAIL PROTECTED]) wrote: > >> I just had the impression that we left the discussion on #IRC with no >> real conclusion, so that's why I wanted to raise the topic again on >> trac-dev. It's nothing /that/ serious, >> > > I take translations quite seriously. As does anyone I know who works on this > kind of subject. There's more involved than 'simple translation'. >
I was saying that /whether to keep the messages.pot in the repository or not/ was nothing that serious. The same for storing periodically the results of automatic runs of extract/updates. I still think that's useless and annoying (especially if done after every 5 or 10 normal commit) as even no actual changes to strings will propagate as hundreds of line offset changes (times the number of .po files), but hey, if you think that serves a purpose (allowing the translators to start working on up-to-date files), well, I'll shut up. I'm not saying that the translation topic is not important, be it the contributions from translators or the i18n work. >> We're only at the beginning, so experimenting should be OK - you had your >> time for experimenting in the sandbox and I didn't join the fun by then, >> but now that i18n is in trunk (and the more urgent stuff for 0.11 is behind >> me) I felt inclined to join the work on i18n, experiment and try to improve >> things there as well. >> > > I am not sure how you intended this, but the way you formulated this is > sounds as if I only had a certain right while this was in the branch. And > the way you proceeded did not give me the feeling of joining, but rather > putting down your view as the only way forward. > No, I only spent a day to /experiment/ with "my" way for updating the catalogs, and this mainly as a side-effect of doing others, more important, contributions to the i18n framework (and /those/ should have deserved a discussion). This doesn't mean that this automatically becomes "the" official way for doing things ever after. At the end of the day, I could even have realized that I was wrong and had missed something which prevented me to understand your arguments. And indeed, I understood that : - you need to have the exact same version of Babel in order to get the same kind of extraction - installing Babel trunk from scratch is not straightforward (but well explained in http://babel.edgewall.org/wiki/SubversionCheckout) - getting the extract/update/compile right is not exactly trivial either, notably the fact that it helps a lot to do an extra update after the manual edits, in order to validate them And therefore I collected all these informations as I was progressing. My take was that with those detailed explanations, translators could do it as well, but I'm quite willing to admit I'm wrong on that point and the purpose of my mail was to discuss *this*, get feedback from translators who would say either "sure, we don't mind, it's better that way" or "are you kidding? are you seriously asking us to do all this?", or anything in between. As feedback has actually been "", feel free to move those detailed explanations about the extract/update commands steps in a === For Developers === section, and keep the simpler workflow for translators (or I'll do it if you want). But after doing this experimentation, I verified at least that a two step commit as I suggested was actually more useful for tracking the changes (a la r7053:7054). And there's nothing revolutionary here, see for example the translation guidelines for the Subversion project (section "Updating existing po files"): ... It is recommended that the .po update is done by using two commits; one after the "make locale-gnu-po-update", and one after the translation is done. This has two advantages: ... (http://svn.collab.net/repos/svn/trunk/TRANSLATING) Btw, those guidelines will be worth looking at again when we'll have to deal with merge of translations. >> Not a big deal really: 0.12/TracInstall presents the minimal things an >> user has to do in order to get the translations and TracL10N is aimed at >> translators and developers with much more detailed instructions. >> > > And TracL10N reflects your opinion on the workflow despite my objections. > I totally do not agree with your stance that people should have to run Trac > to contribute translations. And you have shown that you are not aware how > translations in open source projects get handled, which is quite ok, but > then I am baffled why you put forth your own idea. > Well, you're right, I'm not that aware how things are done elsewhere. However I did look at the french translation, saw the same problems as mentioned by Richard Liao at the beginning of this thread, and fixed them. Besides, I think that translating the Trac strings without at the same time seeing how they are used in context is not optimal because you won't see how the individual translations play together, in a given page. But again, that's only my (not so informed) opinion. > ... I am uncomfortable with especially when objections > seemingly are being overturned. And when that happens I'll just divert my > energy and attention elsewhere since my involvement will not matter anyway. > It does matter. Sorry for all this mess (well, we didn't have a decent flame on Trac-dev since ages, so this is now fixed :-) ). -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
