Re: Modules split proposal (yeah, another one, sorry)
- From: Gil Forcada <gforcada gnome org>
- To: gnome-i18n <gnome-i18n gnome org>
- Subject: Re: Modules split proposal (yeah, another one, sorry)
- Date: Sat, 13 Oct 2012 10:39:06 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]