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

[From: Mohammed Hassan]

On Fri, 2007-10-26 at 19:57 +0300, Marius Vollmer wrote:
> Mohammed Hassan <mohammed.2.hassan at nokia.com> writes:
> 
> > E) I guess it should also be visually distinguishable.
> 
> Precision, Mohammad, precision. :-) What should be visually
> distinguishable from what?  What do you mean with 'visually', i.e., in
> what way is your concept of "visually distinguishable" different from
> "the strings are not equal according to strcmp"?

I meant that the msgid should be visually spottable and preferably
pointing to the UI spec.


> > I can only speak for myself.
> 
> You shouldn't.  You are the Open Source Software Operations
> Localization Engineer in this thread.

No. I'm speaking as the OSSO localization engineer but the opinions are
my personal ones. I also represent myself. I don't represent the user
guidance or l10n testing teams.


> > I think the above approach is not bad but it has a few drawbacks
> > (embedded reply).
> 
> But is it better than the one we have?  Pointing out that a new approach
> isn't perfect is meaningless since no appraoch is perfect.

Better for me ? I don't care much as it's almost the same for me. l10n
testing, user guidance and maybe other parties will be.


> > You (us) might like to also speak to all the parties involved ;-)
> 
> Sure, if they have more substantial things to say.  But I am really
> only interested in a public discussion.

I didn't say we will close it. I only want to get all the parties
involved into the discussion. I don't think any of them will like
changing a process if it's working fine. So we have to talk to them.


> >>  C) code is supposed to get the final string to display by passing the
> >>     UI strings to gettext
> >>
> >> [...]
> >>
> >> Violations of C can be found by comparing the set of UI strings used
> >> by the code with the set specified in the UI spec.  Any mismatch needs
> >> to be dealt with, either by changing the code or changing the spec.
> >> There is no change here compared to our current setup since UI strings
> >> are still precisely identifiable both in code and in the spec.
> >
> > Not really/ How do you get the list of strings inside the code ?
> > xgettext can do that but [only] for strings passed to {n,p,d}gettext.
> 
> Exactly.  xgettext tells you which UI strings are used by the code,
> the UI spec tells you which UI strings are supposed to be used.  If
> there is a string in the UI spec that is not used by the code, that
> could mean that the code doesn't use gettext where it should.  Or that
> the UI spec contains obsolete strings.
> 
> (It is a separate discussion whether it is a good idea to tie the UI
> spec and the code together in such a formal and rigid way.)

This case is not handled although I can check all the domains we have.
but there's also something, a UI spec can be used by multiple packages.


> >> Violations of D can be found by comparing the set of UI strings that
> >> are specified in the UI spec with the set of UI strings actually
> >> translated.  There is no change here compared to our current setup
> >> since UI strings are still precisely identifiable both in the spec and
> >> in the translations.
> >> 
> >> > to easily determine the originating UI spec
> >> 
> >> There is no change here compared to our current setup since UI strings
> >> are still precisely identifiable both in the code and in the spec.
> >
> > Because we are prepending a context ?
> 
> Yes!  (have a cookie.)

I had no lunch until now. Kiitos ;-)


> >> > to design test cases
> >> 
> >> There is no change here compared to our current setup since UI strings
> >> are still precisely identifiable both in the test cases and in the
> >> spec.
> >
> > Visually by the testers too I guess ?
> 
> What do you mean?

What I said earlier. People must be able to spot a "logical ID" during
their normal usage.

> >> If you are interested to find violations to B, you might want to force
> >> the program to show the untranslated UI string identifiers that are
> >> used in the code.  You can still do this by providing the 'identity'
> >> translation from "context|text" to "context|text" that Tollef has
> >> mentioned.
> >
> > No. I don't want to force the application. I want to use the application
> > as a normal user do and spot them.
> 
> Huh?  With 'forcing' I was referring to running the program in such a
> way that it uses the identity translation.
> 
> With our current approach, seeing a logical id in the UI means that
> this UI string has no translation in the current language.  This might
> be a violation of B, or of D.  Bis covered above and for D it is also
> easier and more reliable to mechanically compare the .po files to find
> missing translations.

A logical ID in the interface can be:
* The code uses a logical ID not defined in the spec.
* The coder uses a logical ID from another domain but not depending on
it thus not pulling it into the build
* The coder is not passing the string to gettext
* The l10n packages were not updated for a reason or another.

I've seen cases where the translations are there yet the code was
showing a logical ID (For a reason or another) so manual testing and
spotting is needed.


> [ As a reminder:
> 
>   D) there should be translations of all UI strings in all supported
>      languages (so that gettext has something to return in all cases it
>      is used)
> ]
> 
> >> Some potential actions:
> >> 
> >> - Extend the script that extracts .mpo/.po/.pot/whatever information
> >>   from the UI specs so that it can optionally produce msgids of the
> >>   form "logical_id|Engineering English" (or whatever is appropriate
> >>   for pgettext).
> >
> > Can you do this if needed ? ;-)
> 
> Sure.  Can you?

No. I can't. It's not that I don't want to. It's that I don't know that
programming/scripting language).


> >> - Make a script that replaces "logical_id" with
> >>   "logical_id|Engineering English" (or whatever is appropriate for
> >>   pgettext) in source code.
> >> 
> >> - Tell developers and UI speccers that they can use this approach and
> >>   that then the logical_ids don't need to be unique anymore and don't
> >>   need to include the Engineering English as a hint.
> >
> > They need to be unique.
> 
> No, they don't.  The combination of logical_id plus Engineering
> English needs to be unique.

new logical ID = old logical ID + engineering English

> >> [1] For example, we have a generic information note dialog that can be
> >>     parameterized with the text to display and with the label for its
> >>     single button.  Each use of that information note specifies both
> >>     the text and the button label as new UI strings.  Instead, we
> >>     could specify a specific UI string as the default label of the
> >>     button (and allow uses to overwrite it.)
> >
> > Put it in a library then so all the applications can use it.
> 
> Why did you just say that?  I can only assume that you didn't really
> try to understand what I am writing.

So I still don't. I guess I'm getting a bit lost.


> >> [2] For example, I am right now coding a new statusbar plugin, the UI
> >>     spec is done, but I have no translations yet.  Do I use logical
> >>     IDs in the code?  Of course not, because they are ugly in the UI
> >>     and they mess up the layout too badly.  (And they might not have
> >>     the right formatting codes.)  So I have to go back later and fix
> >>     that, but my motivation is low because I shouldn't have had to
> >>     make this mess in the first place.
> >
> > 'logical_is|Engineering English' will also mess up the layout.
> 
> No, because the "logical_id|" part will not be displayed.

So you want to use gettext contexts ? That's a different issue now.


> > If you are having this problem then you can generate your own PO
> > files from the UI spec. We can work out something.
> 
> Why would I go to this extra effort if we could fix the process so
> that the problem disappears?

Because the process will not be fixed _now_ and because you are coding
that plugin _now_


> Also, I am not primarily interested in my own components here.  There
> are things that each individual component owner should do for
> him/herself, like including the right formatting codes in the logical
> ids (if we stick with them), and reducing excessive context if that
> would improve things.
> 
> But we are talking here about "maemo localization to officially
> non-supported languages".  We need to make that happen for all the
> code we have.

Yes and we are discussing the logical IDs problem as if it's a blocker
while in fact it's not.


> A good way is to use gettext and its tools so that Engineering English
> appears in the msgid, maybe with excessive context in the form of our
> current logical ids.
> 
> We could use Engineering English in the msgid only when interacting
> with 'unsupported' translation efforts, without changing our own
> processes.  (This is your idea, right?)

I never said that. I proposed providing them with POT files suited for
the open source tools and my suggestion was ignored.
Then I discovered it'd be illegal so I'm still following up with our
legal team.


> We could also adopt Engineering English in our msgids internally,
> since it has advantages over using logical ids and no disadvantages
> (as far as I can understand the situation).  And it would remove the
> extra hurdle between external and internal translations.

The above lines mean that we need to restart this thread...


> >> [3] For example, we should have (and use!) the default button label
> >>     for the information note dialog.
> >
> > The default Gtk ones ?
> 
> No, the Hildon information note widget.

This is for the UI spec writers. No iddea why aren't you using it ;-)


> >> [4] For example, we now can change the actual text of a UI string
> >>     without changing its identifier, and the new text will
> >>     automatically pop up in the help texts.  When making Engineering
> >>     English a part of the identifier, we would need to adapt the help
> >>     text.  Not a bad thing, I would say, since you get to review
> >>     whether it all still makes sense.
> >
> > I don't get this one ?
> 
> Last time I looked, help texts make references to msgids and when they
> are typeset, the appropriate translation is substituted for that
> msgid.  In a way, the help texts are 'localizable'.

I know about this. We will need to fix the help files.

-- 
Localization Engineer
OSSO - Nokia Multimedia