Re: Modules split proposal (yeah, another one, sorry)
El ds 13 de 10 de 2012 a les 00:02 +0200, en/na Gil Forcada va escriure: Hi all, See attached (right now I do not have Internet to put that on live.gnome.org at [1]) a new proposal for the modules splitting (related to bug [2]). The current proposal is actually really good, but I think it can be even better (hence my proposal). What I do really don't like is to tie together the libraries with the apps. I completely agree that the strings on the libraries are actually seen, and some of them are quite visible, but if the target still remains to translate everything, let's make it harder at the end rather than at the beginning. That way, when you are more than half-way of the translations and you can **really** see the progress of your work, then, and I think that only then, make sense to finish up the details of that and that other string that show up still untranslated. I know that my current proposal has quite a few rough edges and that it can be put up-side down with some arguments or points of view, but having in mind this new translation teams, or even teams that get usually at 100%, having this small sets of modules makes it more practical to see what's currently left, what's really urgent and what can be delayed for later... ON SMALL MODULES AND METRICS Another think that I had in mind when creating this new proposal was to have a way to, at release notes time, say that not only 50 languages are considered supported, but we could expand that on: - languages with accessibility support: above 80% on accessibility set - languages with developer support: above 80% on the 3 development categories - languages with basic support: above 80% on Core and Core Apps categories - languages with functional support: basic support + 80% on Apps and Core Backend categories - languages with complete support: functional + Utilities, Accessibility, Apps Extras, Games and Backend categories - languages with full support: everything translated (as it is now) That way, with this splitting, some translation teams that could have the desire to start translating the accessibility category (because there people on that language with disabilities and they need to have it first) could still be recognized. The marketing team could do campaigns about developing on GNOME and that it's really easy because XX languages are supported on the development tools. You get the idea, right? ON STRINGS FROM LIBRARIES I think that it would make sense to have a way to show that a module X (say epiphany) depends on strings that comes from Y, Z, A and B (for epiphany: gtk+, webkitgtk, libsoup, gcr...). That way, if a translator really wants to go for 100% translation coverage of a given application (s)he can already see it from the module page itself. Sorry for the long mail, but was meant mostly to put some emphasis that the proposal is not just a random thought when taking a shower, I've been thinking on it for at least a month or so and have come back to it for at least a week daily moving pieces around and thinking about the category names and so on. That does not mean that modules can not be changed around, of course they can be, but I hope that, at least the categories, are well thought enough and will not be completely discarded :) Happy translating and prioritizing! [1] https://live.gnome.org/TranslationProject/SplittingModules [2] https://bugzilla.gnome.org/show_bug.cgi?id=680843 And [1] is already updated :) 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 https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modules split proposal (yeah, another one, sorry)
El dv 12 de 10 de 2012 a les 19:18 -0400, en/na Chris Leonard va escriure: Gil, I would coment that WebKitGTK+ is not on your list, but is required for a completely localized Epiphany experience. I'm still agitating for some improvement (hackish or otherwise) in the WebKitGTK+ failure to produce a valid POT file (for the past two years), but that is a separate matter. cjl I know I know, we have to tackle that point ... What I was trying to say was that instead of keeping in the same category the apps and its libraries (for completeness) if we split them in different categories, we allow the translators do their job for the most important things first, and later, once the main UI is completely translated they can move onto the libraries. Still, with this dependency declaration we can allow a translator to really translate everything that needs to have, say Nautilus, show all strings, no matter where they come from. Cheers, On Fri, Oct 12, 2012 at 6:02 PM, Gil Forcada gforc...@gnome.org wrote: Hi all, See attached (right now I do not have Internet to put that on live.gnome.org at [1]) a new proposal for the modules splitting (related to bug [2]). The current proposal is actually really good, but I think it can be even better (hence my proposal). What I do really don't like is to tie together the libraries with the apps. I completely agree that the strings on the libraries are actually seen, and some of them are quite visible, but if the target still remains to translate everything, let's make it harder at the end rather than at the beginning. That way, when you are more than half-way of the translations and you can **really** see the progress of your work, then, and I think that only then, make sense to finish up the details of that and that other string that show up still untranslated. I know that my current proposal has quite a few rough edges and that it can be put up-side down with some arguments or points of view, but having in mind this new translation teams, or even teams that get usually at 100%, having this small sets of modules makes it more practical to see what's currently left, what's really urgent and what can be delayed for later... ON SMALL MODULES AND METRICS Another think that I had in mind when creating this new proposal was to have a way to, at release notes time, say that not only 50 languages are considered supported, but we could expand that on: - languages with accessibility support: above 80% on accessibility set - languages with developer support: above 80% on the 3 development categories - languages with basic support: above 80% on Core and Core Apps categories - languages with functional support: basic support + 80% on Apps and Core Backend categories - languages with complete support: functional + Utilities, Accessibility, Apps Extras, Games and Backend categories - languages with full support: everything translated (as it is now) That way, with this splitting, some translation teams that could have the desire to start translating the accessibility category (because there people on that language with disabilities and they need to have it first) could still be recognized. The marketing team could do campaigns about developing on GNOME and that it's really easy because XX languages are supported on the development tools. You get the idea, right? ON STRINGS FROM LIBRARIES I think that it would make sense to have a way to show that a module X (say epiphany) depends on strings that comes from Y, Z, A and B (for epiphany: gtk+, webkitgtk, libsoup, gcr...). That way, if a translator really wants to go for 100% translation coverage of a given application (s)he can already see it from the module page itself. Sorry for the long mail, but was meant mostly to put some emphasis that the proposal is not just a random thought when taking a shower, I've been thinking on it for at least a month or so and have come back to it for at least a week daily moving pieces around and thinking about the category names and so on. That does not mean that modules can not be changed around, of course they can be, but I hope that, at least the categories, are well thought enough and will not be completely discarded :) Happy translating and prioritizing! [1] https://live.gnome.org/TranslationProject/SplittingModules [2] https://bugzilla.gnome.org/show_bug.cgi?id=680843 -- 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 https://mail.gnome.org/mailman/listinfo/gnome-i18n -- Gil Forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc:
Re: Modules split proposal (yeah, another one, sorry)
On Sat, Oct 13, 2012 at 4:39 AM, Gil Forcada gforc...@gnome.org wrote: I know I know, we have to tackle that point ... What I was trying to say was that instead of keeping in the same category the apps and its libraries (for completeness) if we split them in different categories, we allow the translators do their job for the most important things first, and later, once the main UI is completely translated they can move onto the libraries. Still, with this dependency declaration we can allow a translator to really translate everything that needs to have, say Nautilus, show all strings, no matter where they come from. Yes, I really do like what you are trying to do. I'm sorry for beating the WebKitGTK+ drum incessantly, but it's importance stems from the fact that web-browsing is one of the most common user activities (and web-errors are common) and so the visibility of the WebKitGTK+ strings is unusually high and will have an out-sized impact on user perception of the L10n experience. I very much like the idea of being able to declare dependencies. Are you thinking of maintaining this manually or through one of the dependency checking mechanisms used by package install processes? There would seem to be distinct advantages and shortcomings to both approaches. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[evolution-mapi] Created branch gnome-3-6
The branch 'gnome-3-6' was created pointing to: 95a5e45... NEWS update for 3.6.0 release. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
