Index: [Article Count Order] [Thread]

Date:  Mon, 14 Jan 2008 13:15:55 +0100
From:  Michael Stauber <bq (at mark) solarspeed.net>
Subject:  [coba-e:11720] Re: Rationalizing BQ localization files?
To:  coba-e (at mark) bluequartz.org
Message-Id:  <200801141315.55866.bq (at mark) solarspeed.net>
In-Reply-To:  <478B4270.1040009 (at mark) enavn.com>
References:  <478745B3.1060704 (at mark) enavn.com> <478B4270.1040009 (at mark) enavn.com>
X-Mail-Count: 11720

Hi Jes,

> Doesn't anyone have any comments about this? :)

No, we're all hiding, hoping that you go away with that suggestion. :o)))

But fun aside, Jes. You make a good point there. There sure is a lot of 
redundancy in the code when it comes to language strings. Yes, some of 
that "fat" could sure be trimmed. But it's a hell of a lot of work.

To *really* cut it down a programmer would need to go through the code with a 
fine toothed comb and then there is also the risk of breaking stuff that 
already HAS been translated. 

> Why not also make the parts of this string, where the actual IP is, in this 
> example in to another string, like:
>
> msgid="gateway_exmpl"
> msgstr=255.255.255.0"
>
> msgid="ip_addr_exmpl"
> msgstr=192.168.1.1"
> 
> and then have the localization engine put in [[ip_addr_exmpl]] or 
> [[gateway_exmpl]] where applicable?

Possible, sure. But that's exactly the kind of stuff that has the potential of 
breaking existing translations. So you'd have to go through the language 
files of ALL languages, fixing that. Or you have to wait until a native 
speaker of that language fixes it.

So don't expect that something happens on that front overnight. Or anytime 
soon. Unless you do it. :o)

-- 
With best regards,

Michael Stauber