Re: Displaying file/folder translations

[danilo gnome org (Danilo Šegan)]

Today at 15:50, Alan Cox wrote:

>> And we'd still end up with broken apps because authors would be
>> unaware that they should actually use gnome_stock_path() instead of
>> hard-coding "Templates" or "Public".  Also, we even had programmers
>> overwrite gconf keys on first run with incompatible values, which
>> means this is as much prone to error as any other approach.
>
> This is easily dealt with: Firstly grep is very good at identifying
> offenders and secondly everyone who makes the mistake while get a hail
> of bug reports from non US users. Yes programmers will make mistakes,
> but they get fixed over time. You break stuff, people fix it.

My point was that this is the same for EAs, .directory (or any other
approach) and "consistency" issue Jeff raised.  Consistency problems
come up only if programmers are not careful, and overwrite already
existing translations with their own values (at least that's the only
complaint Jeff posted).  So, if programmers are not careful, you end
up with "seemingly moving files" in EA scenario, or new, duplicated
folders in GConf scenario (~/Templates and ~/Translated-Templates).
Both of these can be fixed in much the same way: careful, CAREFUL!

[Unless we also take into account the case of translated software
being inconsistent with original since it's, uhm, translated :]

> For a en_* user it means no change. For a non en_* user it might mean a
> few quirks until they get knocked out. Right now i18n for those
> directories is simply broken anyway so a few glitches until it gets
> knocked into shape is still progress.

I see that there're both advantages and disadvantages in any of the
methods (Alexander has raised some issues with GConf approach as well,
we've discussed issues with external, orthogonal translations).  They
all solve the i18n problem, so I'm fine with any of them.  Now we need 
programmers to embrace one (Alexander is particularly *not* fond of
storing path in a GConf key, and gnome-user-share is our "immediate"
concern here).

I cannot influence him (or anybody else for that matter) to go this
route any more than debating it here.  So, we don't have a consensus,
and we need to voice our opinions on one of the following (trying to
influence Alex more than anybody else right now :):

1. don't do anything now (treat translations of folder names as
   orthogonal problem, so it will be solved *eventually*)—basically,
   what Alex does already with g-u-s
   
   Analysis:
    We don't have anyone willing to work on this right away, it has
   some consistency issues, no true way forward either (should we use
   EAs, .directory approach, central translation repository...?), but
   could be fast and easy (a couple of simple system calls) if
   implemented properly (but it could be slow and hard as well :).

   Even if someone had the time to work on this, we'd need to have
   Nautilus maintainers give a go-ahead signal for any/all
   implementation details, since they'll be most affected by this.

   I still think of this as superior solution, though not in every
   aspect (I'm not certain folders having multiple names is a good
   thing).

2. use GConf key—what Alan proposes
   
   Analysis:
    Simple to do right away, will work for everybody, may cause
   problems with non-Gnomey programs or problems with incompatible 
   filesystem encodings, all programs wanting to use stock paths
   would have to go through GConf

Choosing one of these should affect "Templates" and any future
default-folders additions ("Documents", "Pictures", ...), so we
should think it through.  I don't mind the cons of either, since they
both solve problem I find most important: i18n.

Cheers,
Danilo