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
= Overview = The current three categories split (Development tools, Development Platform and Desktop) does fit for the release team and as a platform overview of technologies and what's considered part of the platform (stable and API/ABI guarantees) and what's the desktop (young and experimental not ready for API/ABI guarantees), but does not fit the way a regular user sees GNOME and interacts with. For a translator is more important to translate GNOME Shell than clutter, because the user will see and interact directly with GNOME Shell, but only because of a disaster will see strings coming from clutter. With that in mind, grouping the modules in smaller and more prioritized categories will help them focus on the most important applications before diving into libraries and other modules that, still being important, are more rarely seen into regular day to day usage. The new categories will be the following (look at the notes on each section): What could be considered the GNOME UX Core * GNOME 3 Core * GNOME 3 Core Apps * GNOME 3 Apps * GNOME 3 Core backend What could be considered the GNOME environment * GNOME Utilities * Accessibility * GNOME Apps extras * GNOME Games * GNOME Backend Everything related to development and libraries * GNOME Development Tools * GNOME Core Libraries * GNOME Extra Libraries Legacy stuff at the bottom, not a priority at all * GNOME 2 == GNOME 3 Core == ''Modules'' * gnome-shell * Gtk+ • UI * gdm * gnome-control-center * gnome-online-accounts ''Comments'' Kept simple and minimal, there's no need to put everything on a single category. That's the whole point of splitting the current categories into smaller ones, that new translation teams can see clearly what's more important, it will not be fully translated, but at least the 80% of what's core it will be translated. == GNOME 3 Core Apps == ''Modules'' * epiphany * gnome-boxes * gnome-contacts * gnome-documents * nautilus ''Comments'' Only apps that are already redesigned with GNOME 3 concepts in mind. Again, as in the GNOME 3 Core, keep it straightforward and compact. == GNOME 3 Apps == ''Modules'' * empathy * eog * totem * cheese * evince * gedit * brasero * gnome-terminal * yelp * yelp-xsl ''Comments'' All applications that have entity by themselves but that are still not ported to the new GNOME 3 concepts. == GNOME 3 Core backend == ''Modules'' * gnome-backgrounds * gnome-bluetooth * gnome-desktop * gnome-icon-theme * gnome-initial-setup * gnome-power-manager * gnome-session * gnome-settings-daemon * gnome-themes-standard * sushi * gnome-menus ''Comments'' All "dependency" modules that are used in the categories above (GNOME 3 Core, GNOME Core Apps and GNOME Apps) should be here, that way the translation team at this point will have already translated a fair amount of top priority strings and can start translating the remaining strings that show here and there on those top priority applications. == GNOME Utilities == ''Modules'' * baobab * gcalctool * gnome-font-viewer * gucharmap * file-roller * gnome-system-log * gnome-dictionary * gnome-nettool * gnome-screenshot * gnome-search-tool ''Comments'' All packages that are applications at the end but that they purpose is utility like. == Accessibility == ''Modules'' * caribou * mousetweaks * orca ''Comments'' This one is easy: all applications, meant for users, related to accessibility. Again the libraries that they depend on are further down. == GNOME Apps extras == ''Modules'' * evolution * gnome-packagekit * seahorse * vinagre * vino * gnome-color-manager * gnome-disk-utility * gnome-system-monitor ''Comments'' All categories above are either Core or essential tools/utilities. This category is meant for all other apps that are not in that essential set and that could be considered not mandatory to be on all systems. == GNOME Games == ''Modules'' * aisleriot * gnome-games ''Comments'' An easy one: all games, they split the repositories, we tied them together again. == GNOME Backend == ''Modules'' * gsettings-desktop-schemas * mutter * nautilus-sendto * totem-pl-parser * gnome-keyring * gnome-user-share * gnome-video-effects * libgweather-ui ''Comments'' Once we get to this point, all major apps and the backend of the core interface and apps are already translated, so this category is meant to wrap up all translations meant for packages on any category above that is not meant to be on the GNOME 3 Core backend category. == GNOME Development Tools == ''Modules'' * accerciser * anjuta * devhelp * glade * nemiver * zenity * Gtk+ • properties ''Comments'' All apps, and some libraries, that are focused on development. == GNOME Core Libraries == ''Modules'' * atk * at-spi2-core * clutter * cogl * dconf * evolution-data-server * gdk-pixbuf * GLib * glib-networking * libsoup * gvfs ''Comments'' Note that this is not the Platform Libraries, is the Core Libraries. This distinction is meant so that important, or more generally used libraries can be added here without having to be blessed by the release team. == GNOME Extra Libraries == ''Modules'' * folks * gcr * gtksourceview * json-glib * libgdata * libgnomekbd * libgnome-keyring * libgtop * libgweather-places * libpeas * vte * rygel ''Comments'' All libraries that do not fit on GNOME Core Libraries description. == GNOME 2 == ''Modules'' * PolicyKit-gnome * gnome-panel * gnome-screensaver * libwnck * metacity * network-manager-applet * notification-daemon * gconf * gnome-doc-utils ''Comments'' All apps and libraries that used/meant for the fallback mode and the ones that are supposed to be not widely used anymore because a new app/library that replaces it has been made.
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
