lp-l10n-fr-community team mailing list archive

[Kip Warner <kip@xxxxxxxxxxxxxx>]

On Thu, 2013-06-27 at 11:47 +0200, Nicolas Delvaux wrote:
> Hi Kip,
> 
> You could indeed help translators to produce better translations 
> faster.

Hey Nicolas. Thanks for the constructive feedback.

> First, let me give you a simple example:
> The first untranslated string from VLR in French is currently "Studio 
> Hardware".
> A gettext context is also present but it is just "Studio hardware..." 
> (I don't know if this was intended to be extracted as a gettext context, 
> but you will agree this is not very helpful).

I hear what you're saying. In this case, it's only what it says and the
title case gives an indication for context, albeit perhaps not enough in
this case. The automatic context you are seeing actually isn't provided
by the programmer explicitly to the translator, but is automatically
extracted from the nearest preceding comment in the source code which
may or may not always be useful to the translator. 

I wish there was some way for Launchpad translations to provide a link
for each message to where it is found in the source code for as a last
resort to indicate context if one isn't explicitly provided. There is a
way for gettext to automatically insert file and line numbers into the
generated message catalogue template, but they're not machine readable
by Launchpad as far as I know.

> Personally, I can't translate this string because I don't know what it 
> is referring to.
> Is this a menu item? A window title? A button? (which does what?)
> Is this a kind of editor for hardware? (which hardware?) or is this an 
> hardware implementation of a kind of "studio"?

In this case, it's just a field heading for in the software credits
listing notable software libre used in its creation.

> And, as I said, I just took the first untranslated string ;-)

It's ok. Although most of the successful translations so far on the
software were able to do it, it might have happened faster and easier if
they knew the context better for each string.

> As a volunteer who don't have much free time, I'm not motivated enough 
> to ask you more details about each of these string.

It's ok.

> And, as a user, I would rather see untranslated strings than poorly 
> translated ones.

I'm in agreement.

> There are two ways for you to improve this situation.
> First, you should improve existing gettext contexts and provide them 
> for most (if not all) strings.

From a programmer's perspective, it's actually more difficult than it
sounds. Keep in mind that the software you are translating was mostly
written first, then i18n'd after.

> Secondly, you should document an easy way for translators to actually 
> test the software with and without their translation (gettext context is 
> not always enough, good translations are often tweaked so that the 
> language style is consistent across the app and depending of the UI 
> design where they are actually found).

That process actually isn't unique to this software, but should be
standard across all reasonably compliant GNU Coding Standards friendly
projects. e.g. configuring with --enable-nls, setting LANGUAGE
environment variable, etc. But personally even that standardized
process is still confusing not just for many translators, but
developers too in some cases.

> I'm aware that this may require a lot of work but, well, this is the 
> cost for ensuring a good translation quality when it has to be done by 
> third parties who don't know much (yet?) about your project.

I just realized that you probably didn't see our original post and
that's my fault. I probably should have provided that on the
lp-i10n-fr-community list.

        Hey list,
        
        We are preparing our first public release of our 'Avaneya: Viking
        Lander Remastered' software (VLR). This application is designed to
        recover previously inaccessible NASA photographic mission data taken
        during the first successful mission to the surface of Mars in the
        mid-1970s - the Viking mission. This data became inaccessible for most
        due to technical issues in its archival (e.g. rotting magnetic tapes,
        archaic hardware, proprietary software, etc.).
        
        The application's parent project, Avaneya, is a cerebral science
        fiction game for GNU still in its infancy. We authored the VLR software
        to address our artists' need for photographic reference material within 
        the region of Mars our game takes place in. We rely on this data to
        replicate the environmental conditions as best we can, and users tend 
        to appreciate this.
        
        [...]

        <https://lists.launchpad.net/launchpad-translators/msg00646.html>

Please let me know if you have any further questions.

Take care,

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

Attachment: signature.asc
Description: This is a digitally signed message part