Re: GNOME Moduleset Reorganization vs. L10N
2010/10/18 Dimitris Glezos gle...@indifex.com: On Mon, Oct 18, 2010 at 1:12 PM, Kenneth Nielsen k.nielse...@gmail.com wrote: The solution of having a translations only copy of a module in gnome git, combined with some sort of automatic syncing back and forth, seems to a good solution for the module maintainers that don't mind having this sort of solution. I'm not sure how well this will work. The developer still needs to sync between the trees, and in the past developers found this very frustrating at times. An example is when a developer updates all PO files with new strings and after this he pulls translations from the translation branch. The merge is a nightmare (since git does a git merge instead of a msgmerge). The feedback we received so far is that viable solutions are two: a) pullpush straight to the master branch and b) not push anywhere, just upload the files somewhere and the developer will fetch them when he needs to. In terms of translators this will mean that they can work the way they do now, so this should automatically be ok for translators*. Since it is almost an implementational freebie, is should be ok to have this as the base solution, and then after that determine if we want to add something else. So at this point, can we agree that this can be ONE acceptable solution? Then we could start working setting up the framework for it and actually implement it for the modules that are ok with it. Then we can afterwards continue discussing whether we should/need to add an offer for a external translation framework that is also GNOME approved (e.g. Transifex, Launchpad ,). I like this step-by-step, build-on-what-we-have approach, it's very wise and I usually follow it as well. Admittedly, though, it has a (serious) disadvantage: It only accepts solutions which can build on top of the current way of doing things. This impedes real/radical change. Sometimes radically changing things is good (e.g. when you're in a dead-end). Currently our way of working in GTP is based on files hosted on a VCS, namely git.gnome.org. The challenges are obvious and well explained (although they hardly constitute a dead-end). My humble suggestion is to take this opportunity to really think how effective our way of doing things is. The plan behind Tx 1.0 was to move away from files hosted on a VCS and go to strings (not files) living in a web app (not vcs) which can be imported/exported freely to files. We had both independent projects as well as projects like GNOME behind the decision. It was a really, REALLY hard decision, but we are confident that it's the way things will work in the future and the way to go. Things like upstream/downstream support, translation memory, consistency, per-string suggestions/voting.. they're all possible now. The Q is whether we want to take this opportunity to really re-think how we're doing things, or if we're just going to shift this decision to e.g. 2 years later. Sounds like a good BoF discussion for GUADEC. =) Well, I agree that we should think hard and long about this at some point, because we don't ever want to exclude ourselves from the opportunity to make radical changes. But I really really really don't think that the GNOME 3.0 cycle is the right time to do it. Regards Kenneth ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
2010/10/16 daniel g. siegel dgsie...@gnome.org: On Sat, 2010-10-16 at 03:05 +0200, Kenneth Nielsen wrote: 2010/10/15 daniel g. siegel dgsie...@gnome.org: On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. daniel In the case of clutter core, which I believe was the module that got this discussion started again, Emmanuele said the following: now, how do we go from here to there is probably worth discussing. I cannot move Clutter to gnome.org; it's simply unfeasible for various reasons, one of which is that the Clutter Project is not just used by GNOME. this is similar to GStreamer, or Cairo, which are hosted on freedesktop.org. I think especially the, is not just used by GNOME, argument will be difficult to circumvent. right, but in that case there is no problem to have it hosted on freedesktop.org, like many other dependencies of gnome. Wait what? The very thing that we are discussing, is what to do to ensure localisation quality for this exact kind of module. Even though the source code cannot be hosted on gnome git, we would still like to have control over the localisation, control and easy access. This easiest way to achieve this is to require this kind of module to have their localisation hosted on just one (or possible two) translation services. And what we are trying to find out is, which ones are the right solution. So far a translation only repository copy on gnome git, lauchpad and transifex has been discussed. \Kenneth Regards Kenneth Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
Hallo everyone I think this thread is about reaching the length where we need to make something happen, or nothing will come of it and we are all doomed to repeat the whole thing the next time this issue arises. So lets try and sum up: The solution of having a translations only copy of a module in gnome git, combined with some sort of automatic syncing back and forth, seems to a good solution for the module maintainers that don't mind having this sort of solution. In terms of translators this will mean that they can work the way they do now, so this should automatically be ok for translators*. Since it is almost an implementational freebie, is should be ok to have this as the base solution, and then after that determine if we want to add something else. So at this point, can we agree that this can be ONE acceptable solution? Then we could start working setting up the framework for it and actually implement it for the modules that are ok with it. Then we can afterwards continue discussing whether we should/need to add an offer for a external translation framework that is also GNOME approved (e.g. Transifex, Launchpad ,). Regards Kenneth * Except from the ones that are very discontent with damned lies functionality and want everything moved to another platform. But please realise that that is a different discussion and should be taken in a different thread. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
Hi! Then we can afterwards continue discussing whether we should/need to add an offer for a external translation framework that is also GNOME approved (e.g. Transifex, Launchpad ,). Note that Transifex is not an *external* solution as we would host our own Transifex service on GNOME infrastructure if we decided for it. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
2010/10/18 Johannes Schmid j...@jsschmid.de: Hi! Then we can afterwards continue discussing whether we should/need to add an offer for a external translation framework that is also GNOME approved (e.g. Transifex, Launchpad ,). Note that Transifex is not an *external* solution as we would host our own Transifex service on GNOME infrastructure if we decided for it. Noted, the question still stands. \Kenneth Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On 18 October 2010 06:12, Kenneth Nielsen k.nielse...@gmail.com wrote: [snip details] So at this point, can we agree that this can be ONE acceptable solution? Then we could start working setting up the framework for it and actually implement it for the modules that are ok with it. Then we can afterwards continue discussing whether we should/need to add an offer for a external translation framework that is also GNOME approved (e.g. Transifex, Launchpad ,). I can offer as the maintainer of one of the proposed GNOME Applications that is hosted on Launchpad (deja-dup) to be a guinea pig for that leg of the work. You mentioned that this approach would be no additional work for translators in GNOME. I can add that it would also be no additional work for Launchpad maintainers because they already work with translation branches that they merge before a release. So from that perspective, I like this idea too. -mt ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Mon, Oct 18, 2010 at 1:12 PM, Kenneth Nielsen k.nielse...@gmail.com wrote: The solution of having a translations only copy of a module in gnome git, combined with some sort of automatic syncing back and forth, seems to a good solution for the module maintainers that don't mind having this sort of solution. I'm not sure how well this will work. The developer still needs to sync between the trees, and in the past developers found this very frustrating at times. An example is when a developer updates all PO files with new strings and after this he pulls translations from the translation branch. The merge is a nightmare (since git does a git merge instead of a msgmerge). The feedback we received so far is that viable solutions are two: a) pullpush straight to the master branch and b) not push anywhere, just upload the files somewhere and the developer will fetch them when he needs to. In terms of translators this will mean that they can work the way they do now, so this should automatically be ok for translators*. Since it is almost an implementational freebie, is should be ok to have this as the base solution, and then after that determine if we want to add something else. So at this point, can we agree that this can be ONE acceptable solution? Then we could start working setting up the framework for it and actually implement it for the modules that are ok with it. Then we can afterwards continue discussing whether we should/need to add an offer for a external translation framework that is also GNOME approved (e.g. Transifex, Launchpad ,). I like this step-by-step, build-on-what-we-have approach, it's very wise and I usually follow it as well. Admittedly, though, it has a (serious) disadvantage: It only accepts solutions which can build on top of the current way of doing things. This impedes real/radical change. Sometimes radically changing things is good (e.g. when you're in a dead-end). Currently our way of working in GTP is based on files hosted on a VCS, namely git.gnome.org. The challenges are obvious and well explained (although they hardly constitute a dead-end). My humble suggestion is to take this opportunity to really think how effective our way of doing things is. The plan behind Tx 1.0 was to move away from files hosted on a VCS and go to strings (not files) living in a web app (not vcs) which can be imported/exported freely to files. We had both independent projects as well as projects like GNOME behind the decision. It was a really, REALLY hard decision, but we are confident that it's the way things will work in the future and the way to go. Things like upstream/downstream support, translation memory, consistency, per-string suggestions/voting.. they're all possible now. The Q is whether we want to take this opportunity to really re-think how we're doing things, or if we're just going to shift this decision to e.g. 2 years later. Sounds like a good BoF discussion for GUADEC. =) Now, having said this, I just realized a potential issue with Tx GNOME. Tx 1.0 does NOT support intltool projects which do not have a POT file. More information at the following pages: http://help.transifex.net/user-guide/formats.html#intltool http://help.transifex.net/user-guide/one-dot-zero.html#source-language-file-tracking -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: GNOME Moduleset Reorganization vs. L10N
On Mon, 2010-10-18 at 18:11 +0300, Dimitris Glezos wrote: Now, having said this, I just realized a potential issue with Tx GNOME. Tx 1.0 does NOT support intltool projects which do not have a POT file. More information at the following pages: http://help.transifex.net/user-guide/formats.html#intltool http://help.transifex.net/user-guide/one-dot-zero.html#source-language-file-tracking What about documentation? We translate all of our documentation using po files through xml2po. Can Tx handle DocBook and Mallard documents translated through xml2po? -- Shaun McCance http://syllogist.net/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Mon, Oct 18, 2010 at 6:52 PM, Shaun McCance sha...@gnome.org wrote: On Mon, 2010-10-18 at 18:11 +0300, Dimitris Glezos wrote: Now, having said this, I just realized a potential issue with Tx GNOME. Tx 1.0 does NOT support intltool projects which do not have a POT file. More information at the following pages: http://help.transifex.net/user-guide/formats.html#intltool http://help.transifex.net/user-guide/one-dot-zero.html#source-language-file-tracking What about documentation? We translate all of our documentation using po files through xml2po. Can Tx handle DocBook and Mallard documents translated through xml2po? Yes, like any PO-based project: http://help.transifex.net/user-guide/formats.html#gettext-po-pot-files I created a test project on Transifex* to try it out, here it is: http://test.transifex.net/projects/p/gnome-testing/resource/hig/ If you have credentials on transifex.net, you can try the web-based translation editor on the above URL by logging in and clicking on one of the table rows. -d * Here's how the project was registered $ sudo easy_install transifex-client $ tx init http://test.transifex.net/projects/p/gnome-testing/ $ tx set_source_file C/hig.pot $ tx set_translation -r hig -l de de/de.po $ tx push (translate on Transifex) $ tx pull - en: C/hig.master.pot (source) - fr: fr/fr.po [100%] - es: es/es.po [28%] -- 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: GNOME Moduleset Reorganization vs. L10N
On Sat, 2010-10-16 at 03:05 +0200, Kenneth Nielsen wrote: 2010/10/15 daniel g. siegel dgsie...@gnome.org: On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. daniel In the case of clutter core, which I believe was the module that got this discussion started again, Emmanuele said the following: now, how do we go from here to there is probably worth discussing. I cannot move Clutter to gnome.org; it's simply unfeasible for various reasons, one of which is that the Clutter Project is not just used by GNOME. this is similar to GStreamer, or Cairo, which are hosted on freedesktop.org. I think especially the, is not just used by GNOME, argument will be difficult to circumvent. right, but in that case there is no problem to have it hosted on freedesktop.org, like many other dependencies of gnome. Regards Kenneth Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
Kenneth Nielsen k.nielse...@gmail.com a scris: [snip] In the case of clutter core, which I believe was the module that got this discussion started again, Emmanuele said the following: now, how do we go from here to there is probably worth discussing. I cannot move Clutter to gnome.org; it's simply unfeasible for various reasons, one of which is that the Clutter Project is not just used by GNOME. this is similar to GStreamer, or Cairo, which are hosted on freedesktop.org. I think especially the, is not just used by GNOME, argument will be difficult to circumvent. I don't buy into this argument, it also applies to GTK+... And what about hosting Clutter at freedesktop.org, which Emmanuele seems to imply it would be a good choice? -- mișu pgp004xPI2XmQ.pgp Description: PGP signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
El dv 15 de 10 de 2010 a les 13:29 -0500, en/na Diego Escalante Urrelo va escriure: El vie, 15-10-2010 a las 08:29 -0700, Sandy Armstrong escribió: I'm not a fan myself, but I can see how once a project was already hooked on a Launchpad-oriented process, it would be work to migrate to GNOME infrastructure. Agree, how could we shorten that difference? I think this is the real issue, at least for this part of the proposal. Get a mug, that's a quite long mail, you have been warned! (Added foundation-list since I think the foundation as an umbrella has some of the proposed solutions, see [0] for the previous discussion) Straight to the point, yes, but GNOME as a whole is big enough to not (easily) fit on any other project hosting solution so it's not even feasible (on my humble opinion) to think about getting our own launchpad instance (since launchpad, the software, is free software). Someone up to do an in-depth feature comparison between GNOME infrastructure, Launchpad, SourceForge, Google code and other project hosting solutions? (Note the following list has been collected in 10 minutes and for a person who really doesn't use any of them in detail at all, so big mistakes are sure to be there) From GNOME we have: - Bugzilla - git source control - cgit interface to git - D-L for translations - mailing lists - live.gnome.org for wiki - web hosting (?) - blog hosting - ftp for releases - on-line documentation (http://library.gnome.org) - piwik instance (is open to any GNOME service?) - tomboy on-line ? (when launched) - gtg on-line ? (there have been a GSoC for it) From Launchpad (taken from launchpad.net front page): - bug tracking - code hosting - code reviews (interface to propose branch merges?) - packaging - translations - mailing lists - answers and FAQ - blueprints From SourceForge (taken from http://sourceforge.net/register-project/features.php) - Code hosting - Web hosting - application hosting (mediawiki, trac, wordpress ...) - bug tracking - forums - mailing lists - wiki - blog - file releases - mirroring services (mostly to distribute file releases) - statistics From Google code (taken from http://code.google.com/p/support/wiki/FAQ ) - Project workspaces with simple membership controls - Version control via Subversion (they have other version controls) - Source code browsing and reviews - Issue tracking - Wiki pages - Downloads - Mailing lists at groups.google.com = GNOME missing modules = - For PPA/repository-ready for distributions OBS [1] could be used. - answers/FAQ like web apps could be done with Shapado.com ? - blueprints could be made as bugzilla's tracker bugs? - application hosting ... just resources and admins to take control over - maybe switching cgit to gitorious (the software) ... All in all we don't score that bad on features, but we are missing a big point not shown on the previous listings: integration and self-creation. = Integration = All components described above are shown in a seamless integrated interface, so jumping from code to bugs and back and link blueprints to branches is easy. GNOME has already a single-sign-on infrastructure ([2]?) so as a first integration stages: - integrate everything on GNOME's SSO - create a welcome page much like any other service main page (i.e. http://launchpad.net http://sf.net http://code.google.com) with just pointers to projects and their services - on each module (cgit, bugzilla, wiki...) start integrating other modules pointers via plugins (look and ask the respective projects owners, - bugzilla, dokuwiki, cgit - if they are eager to also work on that and get the code upstream to easily maintain everything = Self-creation = You can go to their platform, create a user and start your project. What should we do in our GNOME infrastructure to allow that? Obviously loads of servers, admins to control them all [3] and resources to pay for all of them (at least servers, volunteers and the already part-time admin can be enough?). == The Foundation role == Quite a few people said that they were more than willing to pay a monthly/yearly fee to get their Tomboy notes on GNOME's servers, also there could be a fundraising campaign on FoG to purchase 3 (more? less?) servers to host all these services. So the Foundation could help here getting the resources to implement that. For example: Exchange a board fee to a brand-new server each year, or a part-time employer work on GNOME's infrastructure? HP, Dell and other hardware manufacturers could be interested in this kind of agreements. As a hardware and software manufacturers they could not see benefits on being on GNOME's advisory board, but they could be interested in this kind of agreements to get their hosted by XX on each GNOME web platform footer. Other small companies who can't afford a board fee could also be interested on that, and even willing to pay a fee (just like github.com) to host their free software there. I'm glad you reached here,
Re: GNOME Moduleset Reorganization vs. L10N
Le vendredi 15 octobre 2010, à 17:02 +0200, daniel g. siegel a écrit : On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. We should improve our infrastructure if possible, sure. But it's a fact that there will be GNOMEy stuff not hosted on gnome.org, whatever we do. So we'll have to find a solution for this anyway. Let's not think that the whole world is wrong, and that we should host everything. Let's be pragmatic and accept that people might have different opinions on what is the best infrastructure :-) Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Sat, 2010-10-16 at 15:53 +0200, Vincent Untz wrote: Le vendredi 15 octobre 2010, à 17:02 +0200, daniel g. siegel a écrit : On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. We should improve our infrastructure if possible, sure. But it's a fact that there will be GNOMEy stuff not hosted on gnome.org, whatever we do. So we'll have to find a solution for this anyway. Let's not think that the whole world is wrong, and that we should host everything. Let's be pragmatic and accept that people might have different opinions on what is the best infrastructure :-) True, but as several people has already said hosting a project in our infrastructure was exciting 8 years ago, but now it is closer than a pain than an excitement. Old-time contributors know how to deal with them, where to ask, where to push, or have access to do it by themselves, etc. but for new contributors it is like offering to host webpages in geocities when there are better choices like wordpress.com, which looks nicer and makes the cooperation easier. FWIW, I like Gil's idea. -- Germán Póo-Caamaño http://www.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. daniel Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, Oct 15, 2010 at 8:02 AM, daniel g. siegel dgsie...@gnome.org wrote: On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. I think this has been well-covered in the past. The typical example is Launchpad, which offers a lot more features in project hosting than we do. Projects get used to using things like blueprints, answers, integrated PPAs, etc. I'm not a fan myself, but I can see how once a project was already hooked on a Launchpad-oriented process, it would be work to migrate to GNOME infrastructure. Sandy ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
El vie, 15-10-2010 a las 08:29 -0700, Sandy Armstrong escribió: I'm not a fan myself, but I can see how once a project was already hooked on a Launchpad-oriented process, it would be work to migrate to GNOME infrastructure. Agree, how could we shorten that difference? I think this is the real issue, at least for this part of the proposal. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, 2010-10-15 at 13:29 -0500, Diego Escalante Urrelo wrote: El vie, 15-10-2010 a las 08:29 -0700, Sandy Armstrong escribió: I'm not a fan myself, but I can see how once a project was already hooked on a Launchpad-oriented process, it would be work to migrate to GNOME infrastructure. Agree, how could we shorten that difference? I think this is the real issue, at least for this part of the proposal. Disclaimer: I HATE BUGZILLA. I HATE BUGZILLA. I HATE BUGZILLA. I've privately reached out to launchpad upstream a few times to see if it is possible to split off the various parts of the monolithic launchpad.net for our own use. The goal was to set it up and see if it would be a good fit for GNOME users/developers. The answer I got was at this time, launchpad is a monolithic project which would be extremely difficult to break up into various pieces. They were friendly and noted that patches to split off things like malone into a bit more stand alone versions would be accepted. However, it isn't really on their roadmap to work on this. Their goals are more aligned towards making launchpad.net as a service rock and keep the source code of it free. Our goals are more aligned towards using bits of launchpad that are really good in places of other things in our own infrastructure. We can't shorted a difference in Canonical's workflow. It seems like the kind of thing that we can't officially sanction but won't discourage if individual package maintainers want to use bzr/lp.net. Would setting up a gnome transiflex and teaching transiflex how to talk more with launchpad help with this any? ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
2010/10/15 daniel g. siegel dgsie...@gnome.org: On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. daniel In the case of clutter core, which I believe was the module that got this discussion started again, Emmanuele said the following: now, how do we go from here to there is probably worth discussing. I cannot move Clutter to gnome.org; it's simply unfeasible for various reasons, one of which is that the Clutter Project is not just used by GNOME. this is similar to GStreamer, or Cairo, which are hosted on freedesktop.org. I think especially the, is not just used by GNOME, argument will be difficult to circumvent. Regards Kenneth Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Moduleset Reorganization vs. L10N
Sorry, I was away for some days and wasn't able to give my opinion sooner. First of all, I'd like to support that using the GNOME infrastructure is invaluable for translators. It is not rare for us to commit in modules, (POTFILES.in, translator comments, other i18n fixes...) and having only one bugzilla to cope with is also very nice. We should continue to encourage developers to use it, but I wonder how we could do this concretely... Returning to basics, I think that to be a GNOME-blessed module at i18n level, the criteria should be that the module is translated through established GNOME translation teams, regardless the tool used. It's not that GNOME teams are the best one, but as others have recently reminded us, it's a matter of consistency and QA. I hope that the release team support this view. Another important point for me is that for any module, only one translation workflow is chosen. That means that different modules might choose different workflows, even if I consider this suboptimal at a team-management level. I can elaborate on this if needed. Now that leaves us with essentially two ways forward: a) each module can choose its preferred tool/workflow and the module owner has to assure that 'commit-like' access is reserved to GNOME teams coordinators. A variant of this would be that a subset of tools are blessed by the GTP, to prevent tool proliferation, which would become unmanageable by coordinators. + free choice for maintainers + does not require any change to current translation tools - duplicated team management - multiple workflows to be familiar with - hard to detect string freezes b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. IMHO, the question about the GNOME main translation stats tool (Damned-Lies or Transifex or whatnot) is secondary, and should be addressed after we've defined where we want to go. Cheers, Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
2010/10/10 Andre Klapper ak...@gmx.net: Hi, in http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00060.html the release-team announced its proposal for a reorganisation of the current modulesets. As the release-team aims at a more decentralized approach for modules that are not part of the GNOME core there are open questions with regard to translation workflows. It would be very welcome to have some discussion about the future role of l10n.gnome.org with regard to translatable modules NOT hosting code on git.gnome.org and/or prefering different infrastructure (e.g. Transifex or Launchpad), and what this means for workflows of translators and integration with l10n.gnome.org. Anybody up? Definitely! Worst case would be a decision without much/enough input from L10N and bad blood afterwards, and that's something to avoid. Absolutely, let get some discussion going. In my optics the purposes we have to keep in mind are: 1) Control. We have to have control over the translations, to make sure that uninformed volunteers don't mess up the quality with grammatical errors of inconsistencies. 2) Easy access to work. It has to be easy for translators to get their hands on the po-files 3) Implementable workflow. It has to be possible and easy to implement a good translation-proofreading-(discussion)-integration workflow. 4) Integration of translations up-stream. Should be automatic. The most visible available options are: A) Translation-only repository copy in git.gnome. B) Launchpad C) Transifex Evaluating how they measure up to our feature requests, it is probably easiest to start with number 2. Any of these solutions allow easy access to translations in them selves. So the main concern is how much we can allow them to become scattered. Using only (A) would results in a status quo in the view of translators. Considering also using (B) or (C), or possibly both, it should be possible to implement a solutions with links in damned lies, thus in effect still maintaining the illusion of a one-point-access to GNOME translations. Now lets look at control (which is absolutely priority alpha). (A) is status quo so fine. Launchpad and Transifex (B and C) are a little more difficult. Per default they will allow anyone access to the translations, which is no good. However, as far as i understand it should be possible to implement the kind of control that we would like to have on both platforms, though the implementation would differ for the two platforms. Launchpad makes it possible to restrict access to module translations to a particular group of people (say gnome-translators, which can then again be partitioned into language groups). So then the only thing we would have to do, is to make a gnome-translators group and require module authors to restrict access to this group. In Transifex you would make a metaproject, containing all the modules that we want control over and then make language specific translations groups for the metaproject. Both of these solutions are _possible_ but do require extra administrative work, so implementing this we probably want to do this for (ideally none, but realistically) only one external tool and absolutely no more than two. Implementable workflow (3). (A) again is status quo, not much to say about that. Transifex (C) (afaik*) workflow revolves around downloading po-files and working with those. So this means that we can work with that in the same way we do now (same translation tools, same e-mail-lists for proofreading and so on). Launchpad (B) is a bit more of a ticklish subject. Launchpad also allows for downloading po-files which result in the same features as above. But the main workflow revolves around a web-interface which has some special characteristics, you have a large translation memory which is a benefit, you also have proofreading functionality but now in another workflow than usual and one that does not allow for direct feedback to contributors. Feedback functionality in the webinterface is planned though. Finally integration upstream. This only ever becomes a problem if we translate stuff in a place that is not the projects primary source of translations. Since in both (A), (B) and (C) they _would_ be the primary source of translations this is not a problem. So what do you think. There are several open questions above. How many if any external tools. Which ones. How well can they be used etc. Please chime in. Regards Kenneth * My knowledge of Transifex is limited I guess it is prefered to respond to the thread on desktop-devel-list mailing list and CC gnome-i18n@ to not have two separate threads on the same topic and to create better understanding/awareness on both sides (developers and translators) for issues. Done. Regards Kenneth Thanks, andre ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
Þann þri 12.okt 2010 12:25, skrifaði Kenneth Nielsen: 2010/10/10 Andre Klapperak...@gmx.net: Hi, in http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00060.html the release-team announced its proposal for a reorganisation of the current modulesets. As the release-team aims at a more decentralized approach for modules that are not part of the GNOME core there are open questions with regard to translation workflows. It would be very welcome to have some discussion about the future role of l10n.gnome.org with regard to translatable modules NOT hosting code on git.gnome.org and/or prefering different infrastructure (e.g. Transifex or Launchpad), and what this means for workflows of translators and integration with l10n.gnome.org. Anybody up? Definitely! Worst case would be a decision without much/enough input from L10N and bad blood afterwards, and that's something to avoid. Absolutely, let get some discussion going. In my optics the purposes we have to keep in mind are: 1) Control. We have to have control over the translations, to make sure that uninformed volunteers don't mess up the quality with grammatical errors of inconsistencies. 2) Easy access to work. It has to be easy for translators to get their hands on the po-files 3) Implementable workflow. It has to be possible and easy to implement a good translation-proofreading-(discussion)-integration workflow. 4) Integration of translations up-stream. Should be automatic. The most visible available options are: A) Translation-only repository copy in git.gnome. B) Launchpad C) Transifex Evaluating how they measure up to our feature requests, it is probably easiest to start with number 2. Any of these solutions allow easy access to translations in them selves. So the main concern is how much we can allow them to become scattered. Using only (A) would results in a status quo in the view of translators. Considering also using (B) or (C), or possibly both, it should be possible to implement a solutions with links in damned lies, thus in effect still maintaining the illusion of a one-point-access to GNOME translations. Now lets look at control (which is absolutely priority alpha). (A) is status quo so fine. Launchpad and Transifex (B and C) are a little more difficult. Per default they will allow anyone access to the translations, which is no good. However, as far as i understand it should be possible to implement the kind of control that we would like to have on both platforms, though the implementation would differ for the two platforms. Launchpad makes it possible to restrict access to module translations to a particular group of people (say gnome-translators, which can then again be partitioned into language groups). So then the only thing we would have to do, is to make a gnome-translators group and require module authors to restrict access to this group. In Transifex you would make a metaproject, containing all the modules that we want control over and then make language specific translations groups for the metaproject. Both of these solutions are _possible_ but do require extra administrative work, so implementing this we probably want to do this for (ideally none, but realistically) only one external tool and absolutely no more than two. Implementable workflow (3). (A) again is status quo, not much to say about that. Transifex (C) (afaik*) workflow revolves around downloading po-files and working with those. So this means that we can work with that in the same way we do now (same translation tools, same e-mail-lists for proofreading and so on). Launchpad (B) is a bit more of a ticklish subject. Launchpad also allows for downloading po-files which result in the same features as above. But the main workflow revolves around a web-interface which has some special characteristics, you have a large translation memory which is a benefit, you also have proofreading functionality but now in another workflow than usual and one that does not allow for direct feedback to contributors. Feedback functionality in the webinterface is planned though. Finally integration upstream. This only ever becomes a problem if we translate stuff in a place that is not the projects primary source of translations. Since in both (A), (B) and (C) they _would_ be the primary source of translations this is not a problem. So what do you think. There are several open questions above. How many if any external tools. Which ones. How well can they be used etc. Please chime in. Regards Kenneth * My knowledge of Transifex is limited I use most of the translation interfaces regularly (Gnome D-L is the only one with real problems pushing translations). I'm even a bit fond of the translationproject robot ;-) Please use Transifex rather than Launchpad. If set up like for Fedora it's quite productive and without a steep learning curve. Can be heavily moderated, with file-locks and other stuff. Don't know if lang-group coordinators can prioritize
Re: Moduleset Reorganization vs. L10N
Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. (That's also what transifex wants to do in the future) Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moduleset Reorganization vs. L10N
El dt 12 de 10 de 2010 a les 16:03 +0200, en/na Vincent Untz va escriure: Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. (That's also what transifex wants to do in the future) Vincent It wouldn't be easier(?) if the non-hosted git.gnome.org applications have a git clone version on git.gnome.org which is cron-updated? Then l10n.gnome.org should make commits in the git.gnome.org version and the maintainer should only had to pick the translations from there. Cheers, -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
On Tue, Oct 12, 2010 at 12:25 PM, Kenneth Nielsen k.nielse...@gmail.com wrote: Implementable workflow (3). (A) again is status quo, not much to say about that. Transifex (C) (afaik*) workflow revolves around downloading po-files and working with those.[...] Transifex has a web based translation tool that lets you do your work online via their online editor called Lotte. As I'm currently the maintainer of the Transifex appliance, getting an instance up and running either on a physical box or a virtual system would be quite simple. Fwiw, the Xfce team uses the appliance. Just my very quick 2 cents. :) -- Og B. Maciel GNOME Foundation Board of Directors 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: Moduleset Reorganization vs. L10N
ti., 12.10.2010 kl. 16.03 +0200, skrev Vincent Untz: Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. But it should also be easy for testers to compile the package with updated translations without having to do make dist I guess. Perhaps documenting how to add an updated translation by just copying the file with the right name into the po/ dir is good enough? Cheers Kjartan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
Hi! Am Dienstag, den 12.10.2010, 18:30 + schrieb Og Maciel: On Tue, Oct 12, 2010 at 12:25 PM, Kenneth Nielsen k.nielse...@gmail.com wrote: Implementable workflow (3). (A) again is status quo, not much to say about that. Transifex (C) (afaik*) workflow revolves around downloading po-files and working with those.[...] Transifex has a web based translation tool that lets you do your work online via their online editor called Lotte. As I'm currently the maintainer of the Transifex appliance, getting an instance up and running either on a physical box or a virtual system would be quite simple. Fwiw, the Xfce team uses the appliance. After some thinking transiflex really looks like a nice solution. I mean, damned-lies is cool but it adds a lot of maintaince work (for Claude). Could we install our own transiflex instance on our infrastructure, e.g. have transiflex.gnome.org or something like that? Can it be integrated with our LDAP server? Can transiflex commit automatically to git.gnome.org once we sorted the security things out? I guess people are still able to update their translations offline with their favourite editor, right? Regards, Johannes signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moduleset Reorganization vs. L10N
2010-10-12 17:41 keltezéssel, Gil Forcada írta: Then l10n.gnome.org should make commits in the git.gnome.org version and the maintainer should only had to pick the translations from there. No, please do not want to rely on then the maintaner will commit the files/merge the branch. He won't, sorry. This is of course the worst case scenario, but we should be prepared for that. For example, we already have two external deps for which the translation process relies on the maintainer committing po files from Bugzilla. Of these two, one maintainer commits such translations, the other(s) do not[1]. Another similar example is GNU TP, where pot files are updated when the maintainer pushes them, and translations are also committed by the maintainer. These events may or may not happen, consequence is that GStreamer stats are out of sync between TP and Damned-lies[2]. This shows to me that expecting the maintainer to push our translations is not a reliable process (it involves busy humans, yay!), so we should try to search for solutions where the only human involved in pushing translations to the repository is the L10N team's committer. Regards Gabor Kelemen [1]: https://bugs.webkit.org/buglist.cgi?query_format=specificorder=relevance+descbug_status=__open__product=WebKitcontent=translation - no finger pointing really, just an illustration. [2]: Compare http://l10n.gnome.org/languages/hu/freedesktop-org/ui/ and http://translationproject.org/team/hu.html ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GNOME Moduleset Reorganization vs. L10N
Hi, in http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00060.html the release-team announced its proposal for a reorganisation of the current modulesets. As the release-team aims at a more decentralized approach for modules that are not part of the GNOME core there are open questions with regard to translation workflows. It would be very welcome to have some discussion about the future role of l10n.gnome.org with regard to translatable modules NOT hosting code on git.gnome.org and/or prefering different infrastructure (e.g. Transifex or Launchpad), and what this means for workflows of translators and integration with l10n.gnome.org. Anybody up? Worst case would be a decision without much/enough input from L10N and bad blood afterwards, and that's something to avoid. I guess it is prefered to respond to the thread on desktop-devel-list mailing list and CC gnome-i18n@ to not have two separate threads on the same topic and to create better understanding/awareness on both sides (developers and translators) for issues. Thanks, andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
