OpenCPN Internationalization ( i18n )

[SamsonovAnton]

Originally Posted by nohal

I suppose that the wrong translation comes from the wxWidgets library localization in this case, so not much we can do about it.

So some voodoo magic is in fact happening in run time? That is all I wanted to hear.

Then provide the correct translation and it should get fixed, shouldn't it? People make mistakes, I honestly don't understand what you suggest we should do about it other than correct them when they are found.

To correct something, one should first need to know what (where) to correct, and that was the problem: I was looking for the resulting string and its parts in templates, and all I saw was either correct translation or no translation at all. I thought that the mistake was mine, although not being able to recall how it was introduced. Thanks for explaining that I am not crazy. :-)

[nohal]

Anton...
There is no voodoo magic at all, the behavior is completely standard in OpenCPN - gettext simply loads wxstd.mo (if available), then opencpn.mo, then opencpn-pluginX_pi.mo. If the later catalog contains a non-null translation of the same string, it overrides the former one.

Pavel

[jongough]

Hi,
OCPN-Draw and Watchdog use an overwrite of the wxWidgets _ macro to make sure the translation for the plugin is used not the first one found. This does mean that all translatable text needs to be translated as you cannot rely on another plugin or opencpn having already done the translation. This may or may not be an improvement, but at least we know where the translation (or miss translation) is coming from.

If other plugins want to use this method there is a pull request on the ocpn provided plugins that does this as well as the 'demo' plugin. Or I can provide the required files. The process is simple and only requires a couple of changes/additions, the main code is left as is. It takes about 5 minutes to do the required work.

Jon

[rgleason]

Also if anyone is interested, see
PlugIn usage of own catalog for Language "strings"
Plugin Languages | Official OpenCPN Homepage

Which Jon wrote up at the time, explaining how it works.

[SamsonovAnton]

Originally Posted by jongough

OCPN-Draw and Watchdog use an overwrite of the wxWidgets _ macro to make sure the translation for the plugin is used, not the first one found. This does mean that all translatable text needs to be translated, as you cannot rely on another plugin or opencpn having already done the translation.

Originally Posted by rgleason

Also if anyone is interested, see PlugIn usage of own catalog for Language "strings".

Guys, you got it all wrong! :-) Strings are like code — they should be reused as much as possible, rather than reinvented by each author in his own manner. If the mainline project makes it difficult to rely on common string base, then it is it that should be fixed — not yours. Once ambiguities are resolved (by switching from concatenation to placeholder formatting, by specifying message context in dubious situations), there will be no need to dishonor “foreign” translations, as they will be 100 % reliable — just as they meant to be.

Moreover, I was going to suggest adding a “common strings” list to the mainline template, so that the text most likely to be shared between plugins is always available — no matter if it is currently used by OpenCPN itself or not.

[rgleason]

Anton,
During internationalization, there was great difficulty having words automatically translated, that needed to be translated into something else.

I believe the reason this occurs is because of ambiquities and double meanings of words that are in a certain context, thus greater control was required. I am certain that Jon and Gilletarom will be able to explain further.

Can you explain your thinking and experience about this problem in greater depth please?

[Hakan]

SamsonovAnton ...
No, spoken language it's not like code.
Code is yes, no and not maybe.
Languages use synonyms and are mostly maybe.
And if all different languages did have similar synonyms it would be easy for the coder but that's not the case. Take the word "port" frequently used here as an example.

English "port" can be used for:
door, gate, gateway, front door, larboard, data interface, harbor,..........and more.
I can easily translate each English synonym to a number of Swedish synonyms. All very different in meaning. I know it's the same in for example French and German and suppose it's the same for Russian.
Have you tried Google translate? Than it's clear translation is close to a science where "maybe" is the leading base, not On or Off.

I think this is the base for the discussion.

Håkan

[SamsonovAnton]

Originally Posted by rgleason

… ambiquities and double meanings of words that are in a certain context, thus greater control was required.

Originally Posted by Hakan

English "port" can be used for: door, gate, gateway, front door, larboard, data interface, harbor,..........and more.

That is exactly what msgctxt is intended for, — a powerful feature not currently used by OpenCPN.

Second, that kind of ambiguity may often be prevented by [slightly] more verbose wording, like “data port”, “sea port” or “port hand” instead of just “port”, — unless extreme brevity is absolutely required in a particular case, which does not happen often, and when it does, just specify the context explicitly.

[nohal]

Anton...
We, or any oher wxWidgets based application, can't use msgctxt, even if we wanted.

Pavel

[Hakan]

Second, that kind of ambiguity may often be prevented by [slightly] more verbose wording, like “data port”, “sea port” or “port hand” instead of just “port”, — unless extreme brevity is absolutely required in a particular case, which does not happen often, and when it does, just specify the context explicitly.

I could though agree to most of that. But it implies that most coders has/get consciousness of the presence of other languages.

But I understand you have a suggestion to solve the issue. Could you explain more in detail, having Pavel's note in mind?

Håkan

[bcn]

Håkan..

normally I would expect a short precise wording in a given language. Optimal usage. It just does not make sense to say "Sea port" or "COM Port" etc. when for the reader/listener/user in English the meaning is clear due to the context.

When you change the idiomatic context - the language - a different wording or expression will be more adequate to explain the content.

Creating "meandering vocabularies" to make the translations more 1:1 is missing the point - my opinion.

The issue how the translation fits into a lay-out is an extra fun...

Hubert

[Hakan]

Hubert
Yes you're right there, of course. What's this is all about is the situation when for example the single word "port" is in one place correct translated to the Swedish word for harbor and further used in a plugin advising when it's time to make a tack. Then is the translation for OCPN prioritized and used also for the plugin regardless of the plugin's translation in Crowdin. So we are then wisely advised to "turn to: harbor" at once.
Ok - slightly fabricated but I think you get the point. There are more real examples when the result is most confusing. (Connect the plug to harbor 1)

Håkan

[jongough]

Hi,
If there is a definite NEED to use both the catalog of the plugin AND the translations supplied by OCPN and all other plugins in a waterfall approach this 'could' be done. However, this would require attempting the translation using the plugin catalog first, then if the translated string is the same as the non-translated string and attempt could be made using the current sort order of catalogs. This would potentially require calling wxGetTranslation twice for each word, i.e. English translated to English translated to English.

This could be done by changing the overwrite macro to be a little more complex, I think.

Jon

[rgleason]

Its worthwhile considering the alternatives to come up with a reliable and simple approach. I think I would favor keeping them separate because of the mechanics and translators, but I really dont know all the ramifications. I know gilletarom had some real problems fetting commands right.

[rgleason]

And jon's approach solved it.