PlugIns and internationalisation

[jongough]

Hi,
I am trying to get ocpn_draw_pi (OD) working correctly with internationalisation. OD displays various rollovers and properties panels which have double (float) type variables which need to be displayed and edited differently depending on the location, i.e. for US English '.'(dot) is used for decimal but French the ','(comma) is used for decimal.

wxWidgets 3.0 supports displaying the correct characters in number fields by using the current locale setting. Also wxWidgets 3.0 supports validators for double/float type variables:

wxFloatingPointValidator<double>

which ensure that the user can only enter characters in keeping with the locale into text fields, i.e. 10.15 for US English and 10,15 for French.

However, OCPN seems to be running with the locale for numeric (LC_NUMERIC) set to "C" which, in effect, is US English. It is possible to change this using wxSetlocale but this affects the whole application, AND, it would appear that wxWidgets do not like this happening. Under Linux all is fine, but under Windows 7 debugging there are numerous assert errors thrown from mainline OCPN code:

..\..\src\common\intl.cpp(1518): assert "wxString::Format("%.3f", 1.23).find(str) != wxString::npos" failed in wxLocale::GetInfo(): Decimal separator mismatch -- did you use setlocale()?If so, use wxLocale to change the locale instead.

where setlocale is being used to change the current locale environment. This happens with OD disabled as well as enabled, so would appear to be independent of the current state of OD.

It would appear that the currently 'accepted' method is to run the whole application in the locale of the user and use std:stringstream to handle output of strings to files with a local locale used for this output. However, this is not the method being used by OCPN 4.2.

Can someone provide guidance on how to handle internationalisation in plugins which will be compatible with OCPN and not interferer with either other plugins or OCPN itself?

Thanks
Jon

[bdbcat]

Jon....

I think we some time ago decided that setlocale(LC_NUMERIC) was the best solution of a tough situation. This means that decimals should be represented as "." in all languages throughout OCPN. And we ignore the Windows asserts in debug mode.

This will be consistent with OCPN core. For instance, Waypoint properties dialog uses "." for lat/lon fields in French, as indeed in all languages.

Not precisely correct, but at least consistent.

Dave

[jongough]

Dave,
The assert issue is easy to get around, just click on the cancel button when it shows and VC wont show that message box again. The error will be shown in the log of what is happening, but I just thought I should mention that there is an issue.

I can easily turn off the localisation of numbers in OD, I just have to comment out a few lines of code. I have only just tried to do the internationalisation as I had users comment that they were having difficulty using the plugin because it used '.'(dot) rather than ','(comma) for the input fields.

If the decision is that all decimal fields in OCPN will use '.'(dot) that is fine by me. I did look at the grib plugin and it shows '.'(dot) and the fields are only output that it appears in. For OD some of the fields the user can enter information and I was being asked to make sure the numbers being entered were sensible, i.e. did not contain two decimal identifiers, only had numbers and could only be entered in the range that was sensible for the data being requested.

But I do think that we need to rationalise the use of locale for the next release. The suggestion of having the real locale being used by default and using the non-localised read/write functions to ensure compatibility for xml/config files is probably the way to go and would not be 'too' much work (I think).

Jon

[NAV]

Originally Posted by jongough

I have only just tried to do the internationalisation as I had users comment that they were having difficulty using the plugin because it used '.'(dot) rather than ','(comma) for the input fields.

If the decision is that all decimal fields in OCPN will use '.'(dot) that is fine by me.

Using '.' (dot) only is ok for all international users, I guess. At least, for us in the Netherlands it's fine.

But the "problem" I encountered so far within Draw (version 641) was a bit different:

I cannot enter a decimal point ("." dot) at all in this field (this field can show decimal figures). I can enter a decimal comma (",") but after entering this I cannot enter a decimal figure.

So for me it was impossible to enter decimal figures at all (although these are shown when the length figure is calculated automatically).

[Gilletarom]

Hello Jongouh,

Originally Posted by NAV

Using '.' (dot) only is ok for all international users, I guess. At least, for us in the Netherlands it's fine.
But the "problem" I encountered so far within Draw (version 641) was a bit different:
I cannot enter a decimal point ("." dot) at all in this field (this field can show decimal figures). I can enter a decimal comma (",") but after entering this I cannot enter a decimal figure.
So for me it was impossible to enter decimal figures at all (although these are shown when the length figure is calculated automatically).

The latest version that we had at our disposal, works great from the point and comma in numbers. Personally, I thank you for having put at the disposal of users, a tool for all types of keyboard.

But if the efforts you made to get there, have resulted in other problems, similar to those I have observed in my tests, then, go back.

Especially as the defects that we noticed prior to your efforts, were of a different nature. We simply asked to be able to type easily, a number at once, without having to type separately mantissa and decimals.

In short, make a final control, upon validation by "Ok" or "Apply" to avoid outlandish values. Ensure that the angles are between -180 ° and + 180 °. Ensure that there is a sequence of acceptable characters with only numbers and a single dot. That should be enough. And probably ask a simpler code.

Best regards. Gilletarom.

[CarCode]

It might be helpful to read the ebook "Cross-Platform GUI Programming with wxWidgets": http://ptgmedia.pearsoncmg.com/image...73816_book.pdf

Even if it is an old book it is still valid for understanding wxWidgets. See page 433 ff. and especially page 443.

Gerhard

[rgleason]

Uwe had a lot of trouble with this using weatherfax_pi I believe. I do not recall all the details, but it it turned out to be a microsoft problem, however for a long time he had to use our American way of localization. Then later after Microsoft fixed it, he switched back. I can dig up the thread easily enough if anyone is interested. We were having Weatherfax bombs until we got to the bottom of it. Uwe is to be credited for his perseverance. The experience might be instructive.

I think we some time ago decided that setlocale(LC_NUMERIC) was the best solution of a tough situation. This means that decimals should be represented as "." in all languages throughout OCPN. And we ignore the Windows asserts in debug mode.

[NAV]

Originally Posted by Gilletarom

The latest version that we had at our disposal, works great from the point and comma in numbers.

In version 649 Draw accepts a decimal comma (",") and then a decimal figure (US keyboard, Dutch language) .

In version 649, Draw doesn't accept a decimal point (".").


OpenCPN 4.2 (route distance) accepts both dots and comma's.

[Gilletarom]

hello NAV, Hello Jongough,

Originally Posted by NAV

In version 649 Draw accepts a decimal comma (",") and then a decimal figure (US keyboard, Dutch language) .
In version 649, Draw doesn't accept a decimal point (".").
OpenCPN 4.2 (route distance) accepts both dots and comma's.

I try the last two versions that Jongough put online. The 648 and, now, 650. I agree, no problem now with the "point" and "Comma".

BUT

I observed serious bug when trying to use the EBL. I'm not certain but I think I have understood that wxWidgets used to solve the problem of "point" and / or "Comma" had serious side effects.
In any case, neither the version 648 or 650 version will solve the bugs encountered.

And even if I'm wrong about "." and ",", I encounter serious bugs. The boat does everything and anything, the O icon bar is partially destroyed.
I add a amazing detail. After experimenting with OPEN Draw 650, when I stop VDR and O, then the next start, the boat was in the Netherlands, is found automatically in England at 53 ° 00.000 N and 0 ° 0,0000E.

Perhaps you've read my posts:
- http://www.cruisersforum.com/forums/...ml#post2038629
- http://www.cruisersforum.com/forums/...ml#post2040427

Please, can you do the same test and tell me if you encounter the same problems?

In a word :
- Start by creating a EBL turn with the boat.
- I chose to 50 ° angle. The 0.25 Nm length. I choice also COG (Using NMEA information) I also choose to show the direction of the line EBL.
- I do move the boat thanks to the VDR one attached file. (In the Netherlands, before Den Helder)

What occur ?

Thank you in advance. Gilletarom.

[rgleason]

Ok, I found the issue in Tracker, it also has links to the Forum Discussion.
It will be worthwhile, I believe to read what happened. Uwe Hur450502 and Marius
FS#1614
Locale problems - Symptom: Glitches in Weatherfax when not set in American style

FS#1614 : Locale problems - Symptom: Glitches in Weatherfax when not set in American style

Lots of water under the dam, and lots of detective work.

http://www.cruisersforum.com/forums/...ml#post1698554

Uwe's report later that it was now fixed.
http://www.cruisersforum.com/forums/...ml#post1701711

[NAV]

Originally Posted by Gilletarom

..... the O icon bar is partially destroyed.
I add a amazing detail. After experimenting with OPEN Draw 650, when I stop VDR and O, then the next start, the boat was in the Netherlands, is found automatically in England at 53 ° 00.000 N and 0 ° 0,0000E.

I didn't carry out the same test yet, but with version 649:
1. I observed an increasing destruction of the icon bar
2. I observed a sudden change in the waypoints of a route (route was destroyed).
3. I observed my position to be moved to the United States.

So far, I haven't looked into this for more details and I have no clue about the cause of this.

[jongough]

I am in the process of removing internationalisation of numbers from the windows version of OD to solve some of the issues. There is definitely something wrong with the windows implementation of wxWidgets and wxLocale. Under linux it all works OK.

Jon

[NAV]

Originally Posted by jongough

I am in the process of removing internationalisation of numbers from the windows version of OD to solve some of the issues. There is definitely something wrong with the windows implementation of wxWidgets and wxLocale. Under linux it all works OK.

Jon

Jon,
Just a simple (stupid?) question. Why can't OD use the same procedure as in OpenCPN?

[jongough]

NAV,
OD did originally just do what OCPN does, but it was requested that the fields be validated to stop users putting in double decimals, characters, out of range values. So I implemented that, but then internationalisation got involved and European users could not enter decimals correctly, although they did display correctly. It turned out that OCPN forces '.'(dot) for decimalisation but wxWidgets use the current global locale to determine whether to use a '.'(dot) or ','(comma). There is an issue in OCPN which shows up in debug mode where the locale is reset after the wxWidgets locale is set. This means that wxWidgets and C++ are now working of different locales and in debug mode causes an assert error to show.

So, for windows I have removed all my changes to validate numbers and provide internationalisation, relying on the current OCPN way of doing things. This means you can enter invalid data in the number fields and it will be taken, but in the translation from text to numbers it will work up until the first 'invalid' translation and will stop there, so if you enter 20,45 you will get 20.00. But at least there should be not sudden movements of the boat (or other strange effects).

I think the way that internationalisation in OCPN is used needs to change to reflect the way that wxWidgets works. The problem here is that it is going to be quite a big change as all files written and read will need to use standard "C/"posix" format to ensure they work, but all displays will need to use the locale of the user. I think Dave may be scheduling this for 5.0 of OCPN.

So in short, the quick way is to put OD back the way it was and allow invalid characters until OCPN can handle locales in a consistent way and surface this to plugins.

Jon

Originally Posted by NAV

Jon,
Just a simple (stupid?) question. Why can't OD use the same procedure as in OpenCPN?

[rgleason]

Hakan do you have any idea of what plugins need language updates for version 4.2. This list might help us all and reduce effort to update plugins.