[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: RFC: Add ISO Currency Code support to KLocale
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2009-11-17 23:37:18
Message-ID: 200911180037.20115.aacid () kde ! org
[Download RAW message or body]

A Dilluns, 16 de novembre de 2009, John Layt va escriure:
> On Sunday 15 November 2009 21:54:05 Albert Astals Cid wrote:
> > Ok, so we aim lower and easy. Ok for me.
> 
> Yep, at least until we think of a way to make it work...
> 
> > Currency Codes are translatable in KSpread, you could try to create a
> >  script seeing how much translations there are where the translation is
> >  different from the original.
> 
> The codes themselves are not translatable, but the Currency Symbol (which
> sometimes matches the Code) are.  I'm useless at scripting, but a quick
>  browse of the ar, el, ru, and zh kspread.po files shows that none of the
>  Symbols appear to actually be translated, not even their national symbols
>  are translated.
> 
> Which is not the same as saying they shouldn't be able to be, just it's not
>  a common thing right now.
> 
> If the Symbols did need translating that makes 5 of the 20 data fields that
> would need translation.  (Note: the 20 data fields x 150 currencies is why
>  I prefer to go with data files rather than a static table or else-if).
> 
> > You have two options:
> > a) Make scripty extract more fields, it's one line of work
> 
> That would be line 57 of createdesktopcontext.pl?  

right

> Would that cause a
> performance issue for scripty to be trying to match every field in every
> desktop file against 5 extra regexp cases?  I wouldn't think so but I'm no
> perl geek :-)

No idea, i'm not a perl person either.

> Would there be any use in a more generic version for kcfg files that you
>  could define a directory or files to be scanned and the set of fields to
>  be extracted?  Would any other applications need such a system, or are
>  most data files in xml these days?

We still lack a proper way to extract for translation arbitratary data files

> 
> > b) Make it translatable manually but not trough .po files like the
> >  DateFormat is translated in kdebase/runtime/l10n/*/entry.desktop
> 
> If it's changing just one line in scripty, how come we don't do it for
> DateFormat?  Too few translations actually required for the overhead?

The thing is that there is one file per "country" so it doesn't make sense 
having DateFormat translated to catalan in the Japanese locale, only in the 
Spanish/French/Italian ones, that's why it isn't scripted.

> So my preferred solution is go with desktop files, have only the Name
> translated for now, so no change needed to scripty.  For the few Symbols
>  that may need translating they can be done manually in the files.  If in
>  future we need more fields translated we can look then at modifying
>  scripty in a generic way.
> 
> How's that sound?

So we only translate the name of the currency?

> 
> Is there anything extra I would need to add to the desktop files to provide
> context?  

You can add
# ctxt: This is a currency
just before the line of the Name= entry if you want

> Anything I would need to do to make sure scripty picks up the
>  files?

Not that i remember.

Albert

> 
> John.
> 

[prev in list] [next in list] [prev in thread] [next in thread]