Using two translation workflows for one module
Dear fellow translators, The solang module has recently joined the GNOME infrastructure, hence the page on l10n.gnome.org. http://l10n.gnome.org/module/solang/ However, they were previously using transifex.net as their platform of (good!) choice. https://transifex.net/projects/p/solang/ My point of view is however that a module should never use more than one tool as "upstream" translation tool. I created a bug report to tell solang maintainers about it. https://bugzilla.gnome.org/show_bug.cgi?id=608627 Could some of you comment on the bug report and bring your opinion on the matter? Thanks. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
We decided to stick to transifex.net for the moment. If you are interested in translating Solang, please head over to: https://www.transifex.net/projects/p/solang/c/master/ Thanks, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Le mardi 23 février 2010 à 03:32 +0200, Debarshi Ray a écrit : > We decided to stick to transifex.net for the moment. If you are > interested in translating Solang, please head over to: > https://www.transifex.net/projects/p/solang/c/master/ Noted. I have launched a thread on gnome-infrastructure [1] to ask if this choice is acceptable for the GNOME community. So go there if you want to contribute to the discussion. [1] http://mail.gnome.org/archives/gnome-infrastructure/2010-February/msg00062.html Cheers, Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
> Noted. > I have launched a thread on gnome-infrastructure [1] to ask if this > choice is acceptable for the GNOME community. Wonderful. You started by asking me about my choice and now when you did not like it, you are trying other means to "win"!. Regards, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Le mardi 23 février 2010 à 10:03 +0200, Debarshi Ray a écrit : > > Noted. > > I have launched a thread on gnome-infrastructure [1] to ask if this > > choice is acceptable for the GNOME community. > > Wonderful. You started by asking me about my choice and now when you > did not like it, you are trying other means to "win"!. I'm sorry if I gave you the impression I want to win. I have nothing to win personally. This is the first time a module uses a different translation workflow, that's why it seems important to me to define if this is acceptable or not for GNOME translation teams. This is often the case when an implicit rule is "broken", it is better to make it explicit, either that the rule has to be enforced or that it should not. I have nothing to decide myself, it has to be a community decision. If there are objective reasons to enforce using our tool, we'll probably do it. But this is still not clearly established. Keep cool :-) Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Am Dienstag, den 23.02.2010, 10:03 +0200 schrieb Debarshi Ray: > > Noted. > > I have launched a thread on gnome-infrastructure [1] to ask if this > > choice is acceptable for the GNOME community. > > Wonderful. You started by asking me about my choice and now when you > did not like it, you are trying other means to "win"!. Please read again Claude's email before criticizing him without any good reason. Stating that Claude "did not like it" is not covered at all by what Claude wrote before. Please don't put words in other people's mouths. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
> Please read again Claude's email before criticizing him without any good > reason. I have read it multiple times and once again right now. > Stating that Claude "did not like it" is not covered at all by > what Claude wrote before. You asked me about my choice. But you never mentioned that if the choice was not going to be l10n.gnome.org then the hosting on git.gnome.org would be in question. This is not nice. You should have mentioned this upfront. Clearly. But this not what happened. So from my point of view it clearly appears to be a case where you ask a question, and when you do not like the answer you try another tactic. Regards, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
> This is the first time a module uses a different translation workflow, > that's why it seems important to me to define if this is acceptable or > not for GNOME translation teams. That is entirely fine and within your rights to do so. However you are now going to the extent of questioning the right to have the Git tree on git.gnome.org. Also please note that many GNOME modules have trees elsewhere. eg., Github or Gitorius. How will you stop someone from messing with the translations on those trees and getting them merged into git.gnome.org? It can be intentional or just an honest mistake. The point I am trying to make is even someone does not use a different localization platform, the chance of non-GNOME translations making it into git.gnome.org is always there. > This is often the case when an implicit > rule is "broken", it is better to make it explicit, either that the rule > has to be enforced or that it should not. Again, it is not clear to me which rule you are talking about. Is it a rule about whether GNOME translators will translate modules not using l10n.gnome.org exclusively (mind the word exclusively)? Or is it a rule about whether the exclusive use of l10n.gnome.org is a binding requirement for hosting on git.gnome.org? > I have nothing to decide myself, it has to be a community decision. If > there are objective reasons to enforce using our tool, we'll probably do > it. But this is still not clearly established. Again, if you do not want to translate Solang, don't do it. Blacklist it in l10n.gnome.org, if you like. But now you are talking about whether it is at all allowed to have the tree on git.gnome.org. For all that I know, you can put into question whether Solang can have its website on projects.gnome.org. > Keep cool :-) Changing primary Git tree locations is not a joke. There is a significant effort involved and the consequences are not trivial. Regards, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
În data de Ma, 23-02-2010 la 03:32 +0200, Debarshi Ray a scris: > We decided to stick to transifex.net for the moment. If you are > interested in translating Solang, please head over to: > https://www.transifex.net/projects/p/solang/c/master/ > Hi, Can we still use l10n.gnome.org for translating Solang? The subject is confusing ... i guess it should be „Using other translation workflow for one module”:) I think the freedom of choice is important, but in the same time we should consider translations quality and the level of reading/background knowledge for person that we would like to help with translations. Also, it would be nice to have a single communication channel for translations. I am not sure if we can bridge notification from all translations system. If we accept Transifex, we should expect to see projects using other systems ... each system with its own communication methods and each system with it's own translation teams. At least for Romanian translations, we have some non-technical translators which are always turned down by the amount of wiki pages they hate to read, command line tools they have to use, mailinglists they have to subscribe and user account they have to create. Are Transifex teams synced with GNOME translations teams? Can we (translators) use the same peer review as in l10n.gnome.org? I am not sure we have the required documentation for Transifex at: http://live.gnome.org/TranslationProject What are the advantages of using Transifex as a translation platform for GNOME? If Transifex offers advantage for GNOME, maybe we should share/document those advantages so other translators are aware of them and use them. Kindest regards, -- Adi Roiban ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Hello There is only one important aspect of this dispute. Where or what is the "up-stream" or simply how translations are "migrating". If l18n.gnome stays on the bottom of the food-chain and does not take updated translations automatically from launchpad, transifex, this-site, that-site, lalala, lilili, ... then there should not be any problems using multiple trees, workflows or anything. If it gets translated elsewhere, then it should not get into gnome without language team approval, if it exists. Someone already gave an idea to notify translators on transifex that solang is being translated on gnome. Just consider hundreds of one time launchpad clickers, updating the work of organized gnome team (to be clear; not all of launchpad users are clickers of course). Solang is being translated by the same team as other gnome translations to Slovenian, no matter where it is hosted, because it's a good project. It just isn't updated regularly, because no-one remembers to check it on transifex. If developers state: "Therefore in cases of conflicts (we have not had any till now) I plan to give preference to the submissions from Damned Lies.", then there should really be no problems. M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
On Tue, Feb 23, 2010 at 14:08, Matej Urban wrote: > Hello > > There is only one important aspect of this dispute. > > Where or what is the "up-stream" or simply how translations are > "migrating". If l18n.gnome stays on the bottom of the food-chain and > does not take updated translations automatically from launchpad, > transifex, this-site, that-site, lalala, lilili, ... then there should > not be any problems using multiple trees, workflows or anything. If it > gets translated elsewhere, then it should not get into gnome without > language team approval, if it exists. Someone already gave an idea to > notify translators on transifex that solang is being translated on > gnome. > Just consider hundreds of one time launchpad clickers, updating the > work of organized gnome team (to be clear; not all of launchpad users > are clickers of course). > > Solang is being translated by the same team as other gnome > translations to Slovenian, no matter where it is hosted, because it's > a good project. It just isn't updated regularly, because no-one > remembers to check it on transifex. I'd say that the real problem is the double effort and the quality. Every time a project is imported from anywhere else to DL, we have to review the complete PO and usually correct dozens, if not hundreds, of mistakes. Many of them because translators not in a team usually follow their own experience and rules to translate, while we have quite strict ones, with reviewers, and so on. Many of us use those translated apps in DL to populate our TM databases, which we trust, but if from time to time projects are imported, then our TM databases are ruined, and more work gets duplicated. No, please, I stand against importing "from time to time" projects into DL, if they are translated elsewhere at the same time. Cheers. -- alor...@gmail.com http://aloriel.no-ip.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
> If it > gets translated elsewhere, then it should not get into gnome without > language team approval, if it exists. This is the part that I do not understand. Does getting into GNOME mean using GNOME infrastructure or being an official module. Solang is not an official module. The reason for using git.gnome.org is one of convenience and alignment. eg., getting our Mallard documentation reviewed, staying upto date with the GNOME Goals, etc.. > Just consider hundreds of one time launchpad clickers, updating the > work of organized gnome team (to be clear; not all of launchpad users > are clickers of course). I do not know about Launchpad because I have never used it. But in Transifex.net developers have the option of allowing anyone to submit or require that new translators or teams ask for permission. Solang requires that new translators/teams ask for permission. > Solang is being translated by the same team as other gnome > translations to Slovenian, no matter where it is hosted, because it's > a good project. It just isn't updated regularly, because no-one > remembers to check it on transifex. Good point. The problem with Tx.net is that there is no way a developer can communicate directly with the l10n community. Ofcourse translators are notified by Tx about string changes, but it is hard for me to say "Hey here is a new program and I would like to have translations for it". I am told work is on to add this feature to Tx. > If developers state: "Therefore in cases of conflicts (we have not had > any till now) I plan to give preference to > the submissions from Damned Lies.", then there should really be no problems. That is a good way to move forward and work together, yes. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
> Also, it would be nice to have a single communication channel for > translations. I am not sure if we can bridge notification from all > translations system. > > If we accept Transifex, we should expect to see projects using other > systems ... each system with its own communication methods and each > system with it's own translation teams. The reason I personally like Transifex.net (not just any instance of Tx) is that it provides a common platform for developers and translators to meet. Not every program is a GNOME program (whatever that means). So it is difficult for those programs to leverage the quality of l10n.gnome.org. Translators just need to sign up to Transifex.net and from there on they can contribute to almost any project for which they have been authorized (either by the language team or the developer of the project). Right now Tx.net can not push to git.gnome.org because Tx does not have an account, but that is different thing. > At least for Romanian translations, we have some non-technical > translators which are always turned down by the amount of wiki pages > they hate to read, command line tools they have to use, mailinglists > they have to subscribe and user account they have to create. I have heard Tx.net is easier. However I am not a translator, so I have no idea how right or wrong that is. :-) > Are Transifex teams synced with GNOME translations teams? No, but I have found a few GNOME translators on Tx.net too. > Can we (translators) use the same peer review as in l10n.gnome.org? Tx.net does have the concept of language teams for a project, but that is not compulsory. Maybe Dimitris can add to this. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
> No, please, I stand against importing "from time to time" projects > into DL, if they are translated elsewhere at the same time. What ways would you suggest to prevent a project hosted on git.gnome.org from being translated in DL because its translation community originated elsewhere? A big fat warning in a README.translators file? Maybe something on the live.gnome.org Wiki? Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Hi! To be clear, I don't think there has ever been an official rule that modules on git.gnome.org have to be translated in damned-lies. This rule is just there for official GNOME modules. Nontheless, this has never been a problem because usually modules get imported in a very early stage without having any translation and people start translating it naturally with damned-lies (as it appears there mostly automatically). Or modules get in because they become official part of GNOME (see above). Now, to my point: If we start as GNOME Translation Project to allow any of the git.gnome.org modules to be translated elsewhere we will end up in a mess of different translation platform with makes it very difficult to keep good quality up! > The reason I personally like Transifex.net (not just any instance of > Tx) is that it provides a common platform for developers and > translators to meet. Not every program is a GNOME program (whatever > that means). So it is difficult for those programs to leverage the > quality of l10n.gnome.org. Translators just need to sign up to > Transifex.net and from there on they can contribute to almost any > project for which they have been authorized (either by the language > team or the developer of the project). Right now Tx.net can not push > to git.gnome.org because Tx does not have an account, but that is > different thing. As a note, developers shouldn't ever decide on translation or who submits a good translation. They just don't know (even for their mother tongue) what the goals and rules of the local translation team are. So, this is the first problem in this concept. And as a last note: We do your care about the translation platform as developer at all? It shouldn't be your job. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
On Tue, 2010-02-23 at 10:03 +0200, Debarshi Ray wrote: > > Noted. > > I have launched a thread on gnome-infrastructure [1] to ask if this > > choice is acceptable for the GNOME community. > > Wonderful. You started by asking me about my choice and now when you > did not like it, you are trying other means to "win"!. Hi Debarshi, There is no need to be so hostile. You feel that Claude is going over your head to remove your options of tools. I understand your frustration, but I think you've jumped too quickly in trying to defend your work. I can tell you that Claude is one of the nicest people I've worked with in Gnome over the years, and he's not out to make developers' lives harder. Please understand that there is a long-standing implicit assumption that anything hosted on (cvs|svn|git).gnome.org uses the Gnome translation teams. I don't know if that's actually written down anywhere, but it's always been my understanding. And I've maintained quite a few packages on gnome.org. I didn't read Claude's email as "you can't use Transifex" but rather "we need to have a discussion to decide what external tools are allowed". Other translators on this list have pointed out the difficulties of dealing with translations imported from external sources. But as you mention, some Gnome translators use Transifex anyway. You point out that with Git, translations could come in from different sources anyway. This is absolutely true. I suppose we expect anybody pushing commits to gnome.org to know what they're pushing, and to respect our teams. But with distributed version control and federated tools like Transifex, questions like these arise, and I don't know that we've figured out how to answer them yet. It's a discussion our community needs to have. Thanks for you understanding, Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
So, to sum up ... If you let gnome teams take over your translations, the translations will be better, syncd with other gnome apps "terminology and desktop" and will sure be updated as soon as strings change. You'll have also less worries. M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Cross posting as I feel this is relevant here as well: On Tue, Feb 23, 2010 at 2:31 AM, Claude Paroz wrote: > So the question is, should we make it an explicit requirement to use > l10n.gnome.org as the main translation platform for a module to be > hosted in GNOME Git? Hi Claude, Short answer: absolutely not. Long answer: As a fellow translator and coordinator for non-GNOME projects, I understand and share the concern over having multiple different "entry points" for translators to contribute to a project. Having said that, however, there is absolutely no difference between Transifex, Pootle, or DL as far as adding complexity to the process of translations. Bear with me here, as I try to explain my logic using a couple of scenarios: Damned Lies: contributors have to register with DL and then ask to be added to a "team" in order to use the web interface to reserve a package for translation. All the work is done offline and then uploaded back to a "holder area" where committers (i.e. those who have a git account on git.gnome.org) have to manually do their review, clone, merge, and push back to the repository. However, nothing stops anyone from cloning the git repository, doing their work offline and submitting it back via bugzilla. Transifex: contributors have to register with Tx.net and depending on the policy for the package mantainer, either request to join/create a team or just starts translating. The translation process itself can be done in many different ways, such as: doing using their inline online web editor, downloading the .po file and doing their work offline, completely ignoring the web ui and cloning the git repository, doing their work offline and submitting it via the web ui, etc. It is up to the project maintainer to decide whether the "submit" process automatically commits the work straight to the upstream repository or receive it as a patch via email for later manual submission. Pootle would sort of have the same model of allowing users to do their work using a web based editor and submitted back. Having explained all that, I am not sure what the real problem is. As you said it on your email, "freedom *is* the key" (my emphasis). There isn't an overhead for anyone involved, really! To make things easier for DL maintainers, you could remove the specific project so that people don't access it via DL or just add a friendly message stating that said project can be translated by accessing this or that url. The project maintainer could also make this very clear from the project's home page and this way avoid getting asked the same question: "how come I cannot translate this via DL?" The most important thing is, and I'm sure you will all agree with me, to get good quality translations added and to lower the entry point for possible contributors to our projects. Disclaimer: I have contributed to both DL (minor) and Transifex and also help administer a Pootle server. Cheers, -- Og B. Maciel omac...@foresightlinux.org ogmac...@gnome.org ogmac...@ubuntu.com GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmaciel.com (pt_BR) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Hi! Debarshi Ray , Tue, 23 Feb 2010 17:12:02 +0200: > > If it > > gets translated elsewhere, then it should not get into gnome without > > language team approval, if it exists. > > This is the part that I do not understand. Does getting into GNOME > mean using GNOME infrastructure or being an official module. Solang is > not an official module. The reason for using git.gnome.org is one of > convenience and alignment. eg., getting our Mallard documentation > reviewed, staying upto date with the GNOME Goals, etc.. You hit the nail on the head actually. One of the main and very important GNOME Goals is i18n/i10n. And we're doing i18n/i10n our own way here in the GNOME Translation Project. We've nice guys in GTP who are developing Damned Lies platform with extensive support for convenient l10n work flow, including the very important (and working!) translation review process. And yes, I think we're kind of proud of it all. That's probably why this discussion is also quite heated, I'd say. So if you really want to comply with the GNOME Goals, you should definitely once again consider making use of the one and only official GNOME l10n platform, and that is l10n.gnome.org. Then I'm sure it'll be a win-win situation, as they say. > > Just consider hundreds of one time launchpad clickers, updating the > > work of organized gnome team (to be clear; not all of launchpad users > > are clickers of course). > > I do not know about Launchpad because I have never used it. But in > Transifex.net developers have the option of allowing anyone to submit > or require that new translators or teams ask for permission. Solang > requires that new translators/teams ask for permission. That's nice, but as others have already mentioned, I think that senior / experienced enough translators should be the primary ones giving "permissions", developers aren't usually the right persons to decide whether translator is doing one's things appropriately. > > Solang is being translated by the same team as other gnome > > translations to Slovenian, no matter where it is hosted, because it's > > a good project. It just isn't updated regularly, because no-one > > remembers to check it on transifex. > > Good point. > > The problem with Tx.net is that there is no way a developer can > communicate directly with the l10n community. Yes, I agree. Moreover, there's no way translators or translation teams on Tx.net can communicate with each other, as the Tx.net translation team approach is based on a per-project basis. That's quite unfortunate in my opinion. Translators and different projects translation teams need to share knowledge, guidelines, terminology, best practices, etc., but having like zillions of different translation teams on one l10n platform isn't aiming to accomplish these important goals. I hope though that the above can be changed in the future and that Tx.net will be more like Damned Lies in this regard. Best, Petr Kovar ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
On Tue, 2010-02-23 at 19:15 +0100, Petr Kovar wrote: > > I do not know about Launchpad because I have never used it. But in > > Transifex.net developers have the option of allowing anyone to submit > > or require that new translators or teams ask for permission. Solang > > requires that new translators/teams ask for permission. > > That's nice, but as others have already mentioned, I think that > senior / experienced enough translators should be the primary ones giving > "permissions", developers aren't usually the right persons to decide > whether translator is doing one's things appropriately. I think the main problem of approach used in Solang project is that it doesn't respect the Gnome hierarchy of translations flow - in general, the coordinator of each respected Gnome l10n team is the main and only point in the whole l10n effort, and his exclusive position is the key to consistency in .po files. Though Solang project puts Gnome coordinator lower than upstream developer which now is in charge of granting permissions to translators and committing (possibly unreviewed) changes in git. I think if Solang upstream developers will respect the existing teams hierarchy (even while using Transifex for translations) then it will be ok. So grant permissions to translators approved, make Gnome l10n coordinator the main person to choose translations to go into the tree - and then we're ok. The usage of separate l10n tool on upstream side is not a very good idea in terms of popularity of the module among potential localizers but at least an approach stated above won't do a mess of Gnome modules. Best regards, Ihar ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
Hi! Og Maciel , Tue, 23 Feb 2010 12:04:57 -0500: (...) > clone, merge, and push back to the repository. However, nothing stops > anyone from cloning the git repository, doing their work offline and > submitting it back via bugzilla. I think that in that case maintainers/developers should be responsible enough to direct such a bug reporter to appropriate translation team or community and not accept translation contributions via Bugzilla. But it may happen, yes. (...) > The most important thing is, and I'm sure you will all agree with me, > to get good quality translations added and to lower the entry point > for possible contributors to our projects. Unfortunately these two things don't always come together. Others have mentioned Launchpad with its (former) open translation approach. Yes, very open and very unfortunate, with very low output quality. So lowering the entry point isn't always the best thing to do. At the same time, you should make sure other things work too in the complex l10n process, but I won't repeat myself here. Regards, Petr Kovar ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
On Tue, Feb 23, 2010 at 8:15 PM, Petr Kovar wrote: > [...] > Moreover, there's no way translators or translation teams on > Tx.net can communicate with each other, as the Tx.net translation team > approach is based on a per-project basis. That's quite unfortunate in my > opinion. Translators and different projects translation teams need to share > knowledge, guidelines, terminology, best practices, etc. > > I hope though that the above can be changed in the future and that Tx.net > will be more like Damned Lies in this regard. Yes, this is something that will be supported in the future. It makes total sense: a software project might want to outsource all its translation user management to another project. But I'd classify this as "project X wants to trust project Y for its translation user management" rather than "collaboration" etc. The bottom line is that sharing and everything happens on mailing lists, not the tools themselves (for now). I hope we can reach a point where the tools will allow a much better collaboration, sharing data, translation memories, etc. > but having like > zillions of different translation teams on one l10n platform isn't aiming to > accomplish these important goals. Indeed, but it'd be fair to notice that neither will one translation team on a zillion L10n platforms. I'll proceed to give some food for thought, 'cause I've been thinking about these bits for a few years now, both as a L10n engineer, as a Fedora Board member, and a project maintainer myself. The biggest Q we need to ask ourselves here is the following: how much does GNOME Translation Project want to insist on being considered the "upstream" for some projects? How is GTP more upstream to Solang than eg. Freedesktop, Fedora or Ubuntu? How much are we willing to tip the scale towards "tightly controlled translation quality" against "cross-project collaboration"? Relaxing this constraint (We are Upstream. We control things) will definitely have some short-term effect on quality. It always happens when you open up things and choose Freedom over Control. You open your door and invite more people. You get more opinions and contributions. But consider this: it could have a positive effect on quantity, and, if we really believe the core open-source mantra of "more eyes = more easy to catch bugs", it could even IMPROVE quality. Good tools and circles of trust can maintain quality. This argument came up with system-config-printer on Fedora. Considering Fedora the upstream for this project doesn't make any sense because translators from a bunch of other communities (including Ubuntu) want to contribute. Insisting too much would lead to a Cathedral (Subversion-like) translation effort. On the other hand, pushing the power to the developer himself being the Upstream (no matter where he's hosted) leads to a Bazaar (Git-like) approach. I'm the developer of Transifex, right? I'd so much love if the GNOME translators could contribute to the translations of Tx itself, and the same for the Fedora and Moblin folks. It'd be a pity if every single of these communities was putting a requirement for their involvement the classic "Our way or the high way". Insisting too much on upstream makes websites like Github (purely Bazaar) seem like they'll never work. But they do. Amazingly well. I know I put too much depth here, but I think some perspective on the topic might do good. -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
On Tue, Feb 23, 2010 at 12:04:57PM -0500, Og Maciel wrote: > Cross posting as I feel this is relevant here as well: > > On Tue, Feb 23, 2010 at 2:31 AM, Claude Paroz wrote: > > So the question is, should we make it an explicit requirement to use > > l10n.gnome.org as the main translation platform for a module to be > > hosted in GNOME Git? > > Hi Claude, > > Short answer: absolutely not. > Long answer: As a fellow translator and coordinator for non-GNOME > projects, I understand and share the concern over having multiple > different "entry points" for translators to contribute to a project. > Having said that, however, there is absolutely no difference between > Transifex, Pootle, or DL as far as adding complexity to the process of > translations. > > Bear with me here, as I try to explain my logic using a couple of scenarios: > > Damned Lies: contributors have to register with DL and then ask to be > added to a "team" in order to use the web interface to reserve a > package for translation. All the work is done offline and then > uploaded back to a "holder area" where committers (i.e. those who have > a git account on git.gnome.org) have to manually do their review, > clone, merge, and push back to the repository. However, nothing stops > anyone from cloning the git repository, doing their work offline and > submitting it back via bugzilla. As a translation coordinator, I never know that people are allowed to submit translations to bugzilla that goes into the tree without language coordinator approval, so the fore mentioned scenario is unlikely to happen, and if it did (like when some one imported translations from launchpad without language coordinators approval), it'll be reverted back. We have l10n teams for a purpose, you know. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using two translation workflows for one module
On Tue, Feb 23, 2010 at 3:16 PM, Khaled Hosny wrote: >> Damned Lies: contributors have to register with DL and then ask to be >> added to a "team" in order to use the web interface to reserve a >> package for translation. All the work is done offline and then >> uploaded back to a "holder area" where committers (i.e. those who have >> a git account on git.gnome.org) have to manually do their review, >> clone, merge, and push back to the repository. However, nothing stops >> anyone from cloning the git repository, doing their work offline and >> submitting it back via bugzilla. > > As a translation coordinator, I never know that people are allowed to > submit translations to bugzilla that goes into the tree without language > coordinator approval, so the fore mentioned scenario is unlikely to > happen, and if it did (like when some one imported translations from > launchpad without language coordinators approval), it'll be reverted > back. We have l10n teams for a purpose, you know. Poor choice of the word "submit" their from my part. I meant the issue can be created in bugzilla and the translation can then be "attached". I should have been a bit more explicit about the part where someone has to review and manually commit the work. Cheers, -- Og B. Maciel omac...@foresightlinux.org ogmac...@gnome.org ogmac...@ubuntu.com GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmaciel.com (pt_BR) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
