Modules split proposal (yeah, another one, sorry)

[Gil Forcada <gforcada gnome org>]

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.