[maemo-developers] Maemo localization to officially non-supported languages

[From: Mohammed Hassan]

On Wed, 2007-10-24 at 15:26 +0300, David Weinehall wrote:
> On ons, 2007-10-24 at 14:41 +0300, Mohammed Hassan wrote:
> > On Wed, 2007-10-24 at 14:19 +0300, David Weinehall wrote:
> > > On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote:
> > > > On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote:
> > > > > On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote:
> > > > > > On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote:
> > > > > > > > The problem is the logical IDs are needed to maintain the smooth
> > > > > > > > process.  It's not easy to simply drop them. I did not say it's
> > > > > > > > impossible. I didn't say it'll be done or it'll not. I'm just saying
> > > > > > > > that they are needed ;-)
> > > > > > > 
> > > > > > > This might be so, but I honestly doubt it.  Can you elaborate?
> > > > > > 
> > > > > > They are used by l10n testing to easily check for untranslated strings
> > > > > > (By me as well), to easily determine the originating UI spec, to design
> > > > > > test cases and I'm sure they have more uses.
> > > > > 
> > > > > msgfmt will happily provide you with statistics about untranslated
> > > > > strings and fuzzy translations, with the added bonus that it can be
> > > > > automated.
> > > > 
> > > > Yes but it will not help differentiation _visually_ between an en_US or
> > > > en_GB string and an Engineering English one.
> > > > 
> > > > It will not help quickly identifying the originating UI spec.
> > > > 
> > > > I got myself into this thread to see what can be done to ease the
> > > > community involvement. I know that logical IDs are one of the problems
> > > > but I'd say it's mainly a problem for developers more than it being a
> > > > problem for localzsers.
> > > > 
> > > > Dropping the logical IDs (If it will happen. I simply do not know) will
> > > > not happen today or tomorrow.
> > > 
> > > Well, of course, the biggest problems currently is the fact that people
> > > are not allowed by the F:ed up license agreement to translate the
> > > software...  But logical strings ARE a big problems for people doing
> > > localisation, unless they're also provided with our localisation
> > > documentation that gives all the information about what the different
> > > logical IDs represent.  Then there's of course the string format issue,
> > > but that is indeed a problem mostly for programmers (but it can
> > > potentially be a big problem).
> > 
> > "Our localisation documentation" is the UI specs ?
> 
> Yes, the UI specs, unless we can have the relevant chapters that
> describe the strings extracted in an easy manner.  I know that it's
> simple to automate for documentation written in sane ways (.tex, for
> instance), but I dunno if Word and similar abominations support it in an
> easy manner.
> 
> > > So if you can manage to convince management that opening all the
> > > localisation documents (all lists of logical IDs and their explanations,
> > > that is), and Nokia legal that the EULA needs to be rephrased, then I
> > > bet most people will be satisfied,
> > 
> > I never checked/had a copy of the EULA. I need to know 1st what do you
> > mean by "localisation documents".
> 
> The relevant information was posted earlier in this thread.

I joined the thread late. Just checked this:
http://lists.maemo.org/pipermail/maemo-developers/2007-October/012057.html

I'll see what can be done.


> > 
> > >  but as a programmer I cannot be happy
> > > until we get proper strings that have the same parameter format as the
> > > real strings, to allow for proper argument checking by the compiler.
> > 
> > This is not my call. Bug the UI spec designer. What I do is to ensure
> > that the format of the translations is the same as the format of
> > engineering English. I guarantee that.
> 
> Well, we're not using engineering English at the moment.

Yes but the translations will be valid if we compare them to a reference
"which is the engineering English"

-- 
Localization Engineer
Open Source Software Operations