On Fri, 2007-10-26 at 19:57 +0300, Marius Vollmer wrote:
> Mohammed Hassan <[EMAIL PROTECTED]> 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
_______________________________________________
maemo-developers mailing list
[email protected]
https://lists.maemo.org/mailman/listinfo/maemo-developers
