On Mon, Jun 08, 2015 at 04:28:06PM +0200, Oswald Buddenhagen wrote: > On Mon, Jun 08, 2015 at 12:09:50PM +0200, Marco Ciampa wrote: > > On Sun, Jun 07, 2015 at 09:29:01PM +0200, Yury V. Zaytsev wrote: > > > Otherwise, shall we at least somehow block people from using Transifex > > > for the languages that are being committed directly to the repository? I > > > do not like the current situation, because it seems that people doing > > > stuff on Transifex are not aware of what's going on the git repository > > > and vice versa. I think it's a really bad scenario when people invest > > > time in doing translations, and their work is just discarded. > > > > > I have always keeped mc translations in sync in many years. I think that > > transiflex is a great tool for missing or poor translations. If there is > > someone (like me) that check periodically translations for completless > > and for behaviour in the "live" program (translate -> compile -> install > > -> test -> commit) I think that is invaluable. > > > > I do not want to "go back" to transiflex. If it will be so, I understand > > and respect your decision, but I'll not continue updating mc in Italian. > > > this is not helpful. what *exactly* is it that makes transifex an > obstacle for you?
1) the lack of / delay of feedback. I have posted some translation strings on Transifex. Now when those strings will be committed exactly? If I have some spare time to do some work on mc I rather prefer to test it right now and not waiting for a day or two for Transifex update when probably I will _not_ have time to test it. 2) not all translations are handled by Transifex right now and I want to contribute in this regard despite of Transifex (lack of) support. See my other mail. 3) translation of menu entries is always a tricky matter due to the space constrictions that the terminal nature of mc impose on translators. This absolutely need immediate test on surce *before* committing any change. 4) Hot keys translations is another problem that mc is particularly susceptible. You have to make sure that hotkeys do not clash when you have to change hotkey due to the lack of a particular letter in your translation. This too need immediate test on surce *before* committing any change. > is it not possible to simply use it as a "buffer" > between the local and the remote repository? Simply not. I am very sorry for this. See above. > is this a setup problem or is it inherent in how tfx works? The second. I think that when there is the total lack of a language translation, tfx could be helpful since it provide and easy way to mass translate a program/document. But the translation *must* be tested/checked and probably corrected by someone during compile time. I am not against to leave tfx for other languages but if a particular language actually *have* enough manpower to maintain its translation at a good level (and ask around, the Italian translation was good), then I think it is better to leave it as it is, through direct git write access (thanks to the GOD of DCVS for the revert command ;-) or through reviewable git patches. Regards, -- Marco Ciampa I know a joke about UDP, but you might not get it. +------------------------+ | GNU/Linux User #78271 | | FSFE fellow #364 | +------------------------+ _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel