On Mon, Jun 18, 2012 at 6:56 AM, David Woodhouse <dw...@infradead.org> wrote: > The OpenConnect VPN client exports a library, libopenconnect, which > handles the fun part of communicating with the server to authenticate. > > This is used from the NetworkManager authentication dialog. > > However, The OpenConnect package lives outside GNOME git and its > translations are handed in Transifex. Its translation coverage is fairly > poor. > > This means that when you use NetworkManager-openconnect in a language > which is fully supported by GNOME, you *still* get to see untranslated > strings where they come from OpenConnect itself. > > I'm pondering "artificially" importing the translatable strings from > OpenConnect into NetworkManager-openconnect, so that they get translated > by the GNOME translation teams and the GNOME user experience for these > languages is much better. > > However, this is technically a trick — I'd be importing strings from > another package *outside* GNOME, which aren't used directly from the > GNOME package, only to "harvest" the translations and put them back into > the non-GNOME package. > > Would that be considered acceptable?
As a downstream that faces this sort of issue more frequently than Gnome probably does given the Gnome position in the software stack, I have tried to resolve similar issues in a variety of ways (as Translation Team Coordinator of Sugar Labs / OLPC), with differing levels of success. In descending order of success from most successful to least successful. 1a) Obtain buy-in from my org (Sugar labs Oversight Board and our parent fiscal sponsor SFC) that offering hosting on our Pootle instance was a wise and acceptable use of our resources in a particular case (AbiWord). Engaging with the AbiWord community and working over time to gain their trust and convince them of the superiority of the hosted solution being offered over existing L10n workflow (complete and mail PO files) and advantages of accessing a larger pool of localizers. Continuing engagement with high levels of responsiveness to AbiWord localizers to maintain trust and smooth the transition. Results: Very successful, win-win-win achieved. (OLPC AbiWord users / AbiWord devs / AbiWord localizers). Results measurable by higher levels of completion and expanded number of languages. http://translate.sugarlabs.org/projects/AbiWord/ Compare stats for 2.8 (pre-Pootle) to 2.9 (post-Pootle) http://www.abisource.com/contribute/translate/ 1b) We have had this arrangement with eToys for a long time, so I am not counting them, but their stuff lives in it's own SVN repo (that we commit to via a special user:pootle given commit privs). POT updates are coordinated periodically. Essentially we share the Pootle instance and the localizers as an ICT educational community resource of the greater Sugar Labs / OLPC / eToys community. 2) Engage with a friendly upstream (Gnome) from whom we inherit a LOT of L10n bits, make polite requests about how to better coordinate, get a very helpful response with the creation of a special "OLPC Release Set" that allows us track our upstream L10n bits and makes it easy for our localizers to identify those bits we use (thanks Claude). Hopefully, also makes it easy for willing upstream localizers to prioritize our L10n bits, if so inclined, as OLPC distributes dual-boot Sugar/Gnome builds providing a fully functional, but somewhat simplified Gnome desktop to millions of kids as an alternative to Sugar UI. http://l10n.gnome.org/releases/olpc/ Results: Hard to measure specifically. Success metrics would include evidence that our localizers were working upstream, or that upstream localizers choose to prioritize our bits. My sense is that this is overall an elegant solution for Sugar/OLPC and we do provide a "trail of breadcrumbs" that our localizers can follow upstream easily, which would benefit Gnome. There are inherent benefits to collaborative / cooperative information exchange and smoothing project to project migration of contributions, but I really can't put hard numbers on how well it has worked out. It is clear that it is a no-lose situation for all parties, so I'll declare it a win. :-) 3) Provide simple "trail of breadcrumbs" for localisers to follow from our L10n infrastructure to other upstream hosted L10n (Gnome, Translate Project, Fedora Transifex, Scratch Pootle instance) for packages we pull. This is done by virtue of creating a dummy project containing dummy PO files that serve the function of tracking tickets. http://translate.sugarlabs.org/projects/upstream_l10n/ The PO is hand crafted (with a spreadsheet) to contain a developer's comment with a link to the upstream L10n hosting for the package and tracking is achieved by dummy "translation" of that package string with "Completed on date X)". Results: Again hard to measure, but I am not that optimistic. Frankly, a number of our localizers find this confusing and end up providing a literal translation instead of following the directions in the developer's comment. The list of upstream packages changes unpredictably over time and there is a significant manual maintenance burden to keeping up-to-date on both the links pointed upstream and their current completion status. Overall, not one I would put in the win column, but not a lose either. 4) Every once in a while, but only for certain languages and certain packages, we will (with the consent of the upstream) host a local copy of the PO file purely for the convenience of a local team that has been specially formed (this happens periodically when a new country buys a bunch of XO laptops) to do a localization sprint. The goal is to collect the strings for that package/language combination (these are usually less-commonly found languages) and eventually upstream them. An example of this is GCompris (thanks Bruno), where we have some South American indigenous language efforts going on. http://translate.sugarlabs.org/projects/GCompris_temp/ Spanish is only present there because it is the bridging language (many of these localizers speaking no English). Results: Too soon to say. No reason this can't work, but it is not a general solution, just a stop-gap before upstreaming. Our preference would be to simply point the localizers upstream, but with these specially formed teams, that is not always feasible and frequently the glibc locales do not exist yet, so the upstream would have trouble hosting them anyway. That is the Sugar Labs experience in these situations, YMMV. Regards, cjl Sugar Labs Translation Team Coordinator http://translate.sugarlabs.org/ _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
