Re: Survey results (yay!)

[Ask Hjorth Larsen <asklarsen gmail com>]

Hi

On Sat, Oct 30, 2010 at 1:24 AM, Khaled Hosny <khaledhosny eglug org> wrote:
> On Sat, Oct 30, 2010 at 12:08:32AM +0100, Gil Forcada wrote:
>> El dv 29 de 10 de 2010 a les 12:52 +0200, en/na F Wolff va escriure:
>> > Op Vr, 2010-10-29 om 00:11 +0100 skryf Gil Forcada:
>> > > Hi!
>> > >
>> > > El dj 28 de 10 de 2010 a les 22:54 +0200, en/na Petr Kovar va escriure:
>> > > > Hi!
>> > > >
>> > > > Gil Forcada <gforcada gnome org>, Sat, 16 Oct 2010 13:11:16 +0200:
>> > > >
>> > > > > Hi!
>> > > > >
>> > > > > I'm really proud (and shamed for the delay) to finally present to all of
>> > > > > you the first survey to our GNOME i18n community!
>> > > > >
>> > > > > First of all, a BIG THANK YOU!! to all coordinators who replied [0]
>> > > >
>> > > > And above all, big thank you, Gil, for this magnificent work! It really
>> > > > uncovers a lot, and enables us to think about our project management &
>> > > > planning in some quite new ways. It was a great idea to conduct such a
>> > > > survey in the first place.
>> > >
>> > > Actually I miserably fail to send the (for me, and I hope for lots of
>> > > teams also) most important point:
>> > >
>> > > In the same way that there's gtk+ and gtk+-properties, i.e. two po files
>> > > for a single module, it would be extremely useful for translators if ALL
>> > > schemas were going to a different po file and thus having a double
>> > > effect on translators:
>> > > - know which strings are actually visible to the users
>> > > - reducing a lot [1] the number of strings to translate to reach the
>> > > glorious 80%
>> > >
>> > > Cheers,
>> > >
>> > > [1] I want to gather some number to enforce my point before sending a
>> > > proposal (if as a gnome-i18n team agree on this) to the release team. If
>> > > anyone wants to spend some minutes getting this data would be lovely :)
>> >
>> > Hallo Gil
>> >
>> > Do you want to find all gconf schema strings?
>> >
>> > If that is what you want to do, it is very easy with pogrep from the
>> > Translate Toolkit:
>> > http://translate.sourceforge.net/wiki/toolkit/pogrep
>> >
>> > If you have all the files in directory/, something like this should give
>> > you what you want:
>> >
>> >   pogrep  --search=locations  "schemas.in"  directory  gconf
>> >
>> > and the output will be written to the gconf directory, containing just
>> > the strings that have "schemas.in" in the #: lines.  Then it is easy to
>> > count the strings and words to work out the percentage:
>> > pocount gconf
>> > pocount directory
>> >
>> > That should give the answer.  I'm quite interested to know this myself!
>>
>> Hi!
>>
>> Thanks for the tips, I already made the numbers:
>>
>> 3158 strings out of 45785 (6.8974%)
>> 35074 words out of 205155 (17.096%)
>>
>> So, just stripping out the gconf/dconf schemas we are getting 17% less
>> words to translate!
>>
>> If we do the same with the errors (much harder to do the analysis
>> though) we could nearly shrink the number of words to translate, at
>> least to 30% (so ~60k words less).
>>
>> On the other side, or to further bold this argument, with the new
>> moduleset proposal made by the release team, more and more applications
>> are going to pop up, so more strings/words to translate...
>>
>> Now that we have the numbers ... what do you think? Would it make sense
>> to propose the release team to ask to create different po files
>> depending on the string type (schema, error and general)?
>
> In Arabic translation, we already avoid translating schema strings and
> text that is only seen in the terminal, so anyway to make this easier
> to handle is highly appreciated (and having separate statistics helps PR
> too :).
>
> Regards,
>  Khaled

To a first approximation I think anything that is marked for
translation should be translated - that's why it's marked for
translation :).  Of course there are some exceptions relating to
names, magic keywors and such.

I think it's a very good idea to split gconf schemas into different
po-files.  Translated gconf schemas are almost worthless to the user,
and disproportionately time-consuming to the translators: They're
highly technical, contain many magic keywords, and are often worded
less well than the UI messages (more ambiguities and prolonged word
compounds).  I sometimes have the feeling that I'm translating strings
that will only be seen by the poor sod who proofreads them.

Error messages should still be translated on par with the UI in my
opinion.  A 'network error' message when the network isn't connected
is somewhat common, and technically it would be very difficult to
distinguish this kind of common error message from obscure internal
programming errors that are not expected to happen at all  And there
may not be that many of those.

Best regards
Ask