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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.10.2010 14:32, schrieb Gil Forcada: 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. snip 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. You are absolutely right. Most of the pieces are already available but work as separate, independent parts where each component is not aware of the existence of others. This makes navigating through a projects resources difficult. What I like about launchpad/sourceforge is that it doesn't matter which project it is, the project's website always looks the same. Therefore, the link to the bug tracker etc. is always at the same position. Whereas on projects.gnome.org everything looks different. If we could unify the websites' layout and put all relevant links like Gil mentioned on the front page, this would be a big improvement. In addition, as a maintainer when comes release time you have to - - upload the tarball - - tag release in git - - send announcement to gnome-announce-list and project's mailing list - - update your website and/or live.gnome.org If one could do all these things in a single step by just uploading the tarball (after all, everything relevant should be mentioned in NEWS) that would be perfect. I understand that those are difficult and time consuming tasks, but I just wanted to mention that what I think GNOME infrastructure needs desperately is integration. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzAWmQACgkQ1ygZeJ3lLIfq0QCfSiIsY2zRs5+SauI8rqySYiUk aZwAoI4PU+Cb4txbDg96PYyFy31OMqPa =Wpqw -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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-i...@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-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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-i...@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-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, 2010-10-15 at 22:15 +0200, Claude Paroz wrote: Le vendredi 15 octobre 2010 à 13:29 -0500, Diego Escalante Urrelo a écrit : 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. We are already rich: We have the bug tracker (bugzilla), we have the VCS (Git/cgit), we have translation stats (D-L), we have build bots, we have a documentation library, an FTP server, ... What's missing IMHO is some glue which could integrate those various quality components in a comprehensive Web platform. Well, if I'm relieved from D-L, I might look one day into this :-) do you mean, to have all those services on the project pages, instead each of it on it's own subdomain? if so, maybe it is worth a try to integrate it. But we are digressing from the initial thread. Claude -- www.2xlibre.net ___ desktop-devel-list mailing list desktop-devel-list@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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Sat, 2010-10-16 at 10:21 +0200, daniel g. siegel wrote: 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. it's inconsequential: the whole problem is having it, or not having it, on the gnome.org server - because of authentication and access problem. it doesn't matter where it is: freedesktop.org, clutter-project.org, launchpad.net - they all are *not* gnome.org. as I said, I cannot move Clutter's authoritative repository from clutter-project.org. it's perfectly fine for the GNOME I18N project to have a repository for translation purposes - and I'll gladly resync the translations at every release. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Sat, 2010-10-16 at 12:32 +0200, daniel g. siegel wrote: right, but in that case there is no problem to have it hosted on freedesktop.org, like many other dependencies of gnome. it's inconsequential: the whole problem is having it, or not having it, on the gnome.org server - because of authentication and access problem. it doesn't matter where it is: freedesktop.org, clutter-project.org, launchpad.net - they all are *not* gnome.org. actually there is a subtle difference here, quote: I know perfectly well what fd.o is, thank you very much. the problem at hand is access - and hosting on fd.o has the same issues as hosting on launchpad or clutter-project.org, or github: translators want direct access to bypass the maintainers because they feel (actually: because they made abundantly clear) that the maintainers are a bottleneck[0]. again, if direct access to the repository is the goal then any hosting *except* git.gnome.org is going to be a problem. however, if we are talking about applications and end user software your notion is of course totally right. I'm talking about *any* project. ciao, Emmanuele. [0] personally, I don't believe for a minute that this is true. yes, i18n is hard and we should all go shopping instead - *but* my past experience with direct access from translator coordinators has been spotty at best: wrong or partial commits, build breakage, delayed releases because of commits slap bang in the middle of a distcheck, you name it. after all these years, I came to the conclusion that I'd rather have all i18n effort go through a branch and never to master; or, better yet, go through email and automated notifications; or even a tool like transifex's command line client. in these cases I can at least retain a modicum of control on projects that I (and not the i18n teams) maintain. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
Hi! I know perfectly well what fd.o is, thank you very much. the problem at hand is access - and hosting on fd.o has the same issues as hosting on launchpad or clutter-project.org, or github: translators want direct access to bypass the maintainers because they feel (actually: because they made abundantly clear) that the maintainers are a bottleneck[0]. again, if direct access to the repository is the goal then any hosting *except* git.gnome.org is going to be a problem. You are oversimplifying things! Actually the translation project would be glad if we could avoid giving direct repository access to everybody. We would love to have a tool like transifex/improved d-l/whatever doing the i18n commits in which case most of the problems with broken commits you mention do not exist. However, in the past the maintainers simple have been a bottleneck when committing translations. And as such it is understandable that translators don't like to rely on anybody for committing their translations. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
2010/10/12 Johannes Schmid j...@jsschmid.de: 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? We are getting off topic here. The problem at hand is how to handle projects that will/can not have their code hosted on gnome servers, settings up an gnome instance of transifex will not solve that. What we here need to figure out is, when people don't want their main code repository hosted at gnome, then how do we handle that. Please comment on that, as it will be an important decision for our workflow. Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, Oct 15, 2010 at 11:14 AM, Kenneth Nielsen k.nielse...@gmail.com wrote: 2010/10/12 Johannes Schmid j...@jsschmid.de: 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? We are getting off topic here. The problem at hand is how to handle projects that will/can not have their code hosted on gnome servers, settings up an gnome instance of transifex will not solve that. I suspect a GNOME instance of Transifex will solve this, as long as the upstream maintainer chooses to use GTP instead of another translation community. What are our main problems for projects not hosted on GNOME servers? -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
Hi! I suspect a GNOME instance of Transifex will solve this, as long as the upstream maintainer chooses to use GTP instead of another translation community. What are our main problems for projects not hosted on GNOME servers? The main problem is that external projects often don't allow translators/Transiflex to commit the translation directly to the repository. This adds a manual step in the translation process which doesn't always work as we have seen in the past with various freedesktop and other projects. Some maintainers simply aren't able to handle the extra workload in time so we have delays especially in the development versions. And of course even commiting to git.gnome.org from an automatic system hasn't been handled yet because of security issues. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, Oct 15, 2010 at 12:14 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! I suspect a GNOME instance of Transifex will solve this, as long as the upstream maintainer chooses to use GTP instead of another translation community. What are our main problems for projects not hosted on GNOME servers? The main problem is that external projects often don't allow translators/Transiflex to commit the translation directly to the repository. This adds a manual step in the translation process which doesn't always work as we have seen in the past with various freedesktop and other projects. Some maintainers simply aren't able to handle the extra workload in time so we have delays especially in the development versions. And of course even commiting to git.gnome.org from an automatic system hasn't been handled yet because of security issues. Starting from 1.0, Transifex no longer forces commits to VCS. Yay. :-) Instead, Transifex hosts the translations internally and allows their exporting to regular PO files. This way, both language coordinators and project maintainers can use a command-line tool to regularly export translations and commit them to any repository they please (cronjobs supported too). (Note that offline translation is also supported.) Full information can be found here: http://help.transifex.net/user-guide/one-dot-zero.html -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, Oct 15, 2010 at 12:42 PM, Johannes Schmid j...@jsschmid.de wrote: Starting from 1.0, Transifex no longer forces commits to VCS. Yay. :-) We want forced commits! We don't want people to care about translations unless they are translators because we found out in the past that some won't care. If the maintainer has to commit translations manually - that's a pain! Yeah, this is a common challenge with maintainers. =) The command-line tool can be quite flexible though. Here are some proposed workflows: 1. Language leaders can run something like `tx pull --release gnome/3-0 --language pt_BR` and mass-commit their language before the translation deadline, for example. 2. Developers can put into their 'make release' Makefule rule the `tx pull` command, which exports all translation files from Tx. 3. We can easily setup a script to do all these in a batch mode once per day, or even dynamically using a web hook. -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, 2010-10-15 at 12:59 +0300, Dimitris Glezos wrote: On Fri, Oct 15, 2010 at 12:42 PM, Johannes Schmid j...@jsschmid.de wrote: Starting from 1.0, Transifex no longer forces commits to VCS. Yay. :-) We want forced commits! We don't want people to care about translations unless they are translators because we found out in the past that some won't care. If the maintainer has to commit translations manually - that's a pain! Yeah, this is a common challenge with maintainers. =) The command-line tool can be quite flexible though. Here are some proposed workflows: 1. Language leaders can run something like `tx pull --release gnome/3-0 --language pt_BR` and mass-commit their language before the translation deadline, for example. Is that something that's done per-module? Our release sets have well over 100 modules. That would be a real pain for translators. Also, there's no real translation deadline in Gnome. The deadline is the release. And we want the translations to be in all the unstable releases as well. They should be available in git (or wherever) as they are updated. 2. Developers can put into their 'make release' Makefule rule the `tx pull` command, which exports all translation files from Tx. I would really prefer distcheck not to hit the network. 3. We can easily setup a script to do all these in a batch mode once per day, or even dynamically using a web hook. I think this is the only thing that would work for Gnome. A daily cron job (or maybe twice-daily) seems reasonable, but I'd be worried about missing last-minute translations in our releases. Perhaps we'd have to implement an actual translation deadline. -- Shaun McCance http://syllogist.net/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, Oct 15, 2010 at 4:27 PM, Shaun McCance sha...@gnome.org wrote: On Fri, 2010-10-15 at 12:59 +0300, Dimitris Glezos wrote: On Fri, Oct 15, 2010 at 12:42 PM, Johannes Schmid j...@jsschmid.de wrote: Starting from 1.0, Transifex no longer forces commits to VCS. Yay. :-) We want forced commits! We don't want people to care about translations unless they are translators because we found out in the past that some won't care. If the maintainer has to commit translations manually - that's a pain! Yeah, this is a common challenge with maintainers. =) The command-line tool can be quite flexible though. Here are some proposed workflows: 1. Language leaders can run something like `tx pull --release gnome/3-0 --language pt_BR` and mass-commit their language before the translation deadline, for example. Is that something that's done per-module? Our release sets have well over 100 modules. That would be a real pain for translators. This could be done on the whole release. There's an API which we can fully take advantage and extend. Also, there's no real translation deadline in Gnome. The deadline is the release. And we want the translations to be in all the unstable releases as well. They should be available in git (or wherever) as they are updated. 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. 2. Developers can put into their 'make release' Makefule rule the `tx pull` command, which exports all translation files from Tx. I would really prefer distcheck not to hit the network. Me too. Maybe a warning to pull the translations if you're doing a new release. 3. We can easily setup a script to do all these in a batch mode once per day, or even dynamically using a web hook. I think this is the only thing that would work for Gnome. A daily cron job (or maybe twice-daily) seems reasonable, but I'd be worried about missing last-minute translations in our releases. Perhaps we'd have to implement an actual translation deadline. An actual translation deadline has a few advantages, mainly confidence in the translators' minds (whatever I do until that time will be included in the release, anything later might or might not get included). FWIW, we're going to implement string freeze translation deadline support in Transifex itself soon (mainly emitting notifications on string freeze braking detection and when the deadline approaches). Hope this helps! -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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-i...@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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
Le vendredi 15 octobre 2010 à 13:29 -0500, Diego Escalante Urrelo a écrit : 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. We are already rich: We have the bug tracker (bugzilla), we have the VCS (Git/cgit), we have translation stats (D-L), we have build bots, we have a documentation library, an FTP server, ... What's missing IMHO is some glue which could integrate those various quality components in a comprehensive Web platform. Well, if I'm relieved from D-L, I might look one day into this :-) But we are digressing from the initial thread. Claude -- www.2xlibre.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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-i...@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-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Moduleset Reorganization vs. L10N
2010/10/12 Kenneth Nielsen k.nielse...@gmail.com: 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
Fwd: GNOME Moduleset Reorganization vs. L10N
Hi Sveinn I made the mistake of sending it to the gnome-devel-list instead of as it should have been, the desktop-devel-list, so I'll forward your email. -- Forwarded message -- From: Sveinn í Felli svei...@nett.is Date: 2010/10/12 Subject: Re: GNOME Moduleset Reorganization vs. L10N To: Cc: gnome-devel-l...@gnome.org, GNOME i18n list gnome-i...@gnome.org Þ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
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
