Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 09-02-2016, 19:57   #1
Registered User

Join Date: May 2013
Location: NSW, Australia
Boat: Richter 42
Posts: 883
PlugIns and internationalisation

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:
Code:
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:
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
Attached Thumbnails
Click image for larger version

Name:	setlocale assert error under windows.png
Views:	88
Size:	60.0 KB
ID:	118684  
__________________

__________________
jongough is offline   Reply With Quote
Old 09-02-2016, 22:40   #2
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,884
Re: PlugIns and internationalisation

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
__________________

__________________
bdbcat is offline   Reply With Quote
Old 09-02-2016, 23:12   #3
Registered User

Join Date: May 2013
Location: NSW, Australia
Boat: Richter 42
Posts: 883
Re: PlugIns and internationalisation

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
__________________
jongough is offline   Reply With Quote
Old 10-02-2016, 01:19   #4
NAV
Registered User

Join Date: Sep 2010
Location: Netherlands
Posts: 424
Re: PlugIns and internationalisation

Quote:
Originally Posted by jongough View Post
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).
__________________
NAV is offline   Reply With Quote
Old 10-02-2016, 02:51   #5
Registered User
 
Gilletarom's Avatar

Join Date: Mar 2010
Location: France
Boat: 10.50 mètres
Posts: 2,295
Re: PlugIns and internationalisation

Hello Jongouh,
Quote:
Originally Posted by NAV View Post
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.
__________________
Gilletarom is offline   Reply With Quote
Old 10-02-2016, 03:18   #6
Registered User

Join Date: Jul 2010
Location: Monastir, Tunisia
Boat: Amel Sharki
Posts: 1,777
Re: PlugIns and internationalisation

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
__________________
CarCode is offline   Reply With Quote
Old 10-02-2016, 05:55   #7
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,407
Re: PlugIns and internationalisation

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.

Quote:
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.
__________________
rgleason is offline   Reply With Quote
Old 10-02-2016, 07:39   #8
NAV
Registered User

Join Date: Sep 2010
Location: Netherlands
Posts: 424
Re: PlugIns and internationalisation

Quote:
Originally Posted by Gilletarom View Post
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.
__________________
NAV is offline   Reply With Quote
Old 10-02-2016, 09:26   #9
Registered User
 
Gilletarom's Avatar

Join Date: Mar 2010
Location: France
Boat: 10.50 mètres
Posts: 2,295
Re: PlugIns and internationalisation

hello NAV, Hello Jongough,
Quote:
Originally Posted by NAV View Post
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:
- Ocpn-Draw and Boundary
- Ocpn-Draw and Boundary

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.
Attached Files
File Type: pdf 2013-07-09-Mardi_Den-Helder_Ile_de_Texel.zip.pdf (486.4 KB, 19 views)
__________________
Gilletarom is offline   Reply With Quote
Old 10-02-2016, 16:22   #10
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,407
Re: PlugIns and internationalisation

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.

WeatherFax ...

Uwe's report later that it was now fixed.
WeatherFax ...
__________________
rgleason is offline   Reply With Quote
Old 11-02-2016, 00:46   #11
NAV
Registered User

Join Date: Sep 2010
Location: Netherlands
Posts: 424
Re: PlugIns and internationalisation

Quote:
Originally Posted by Gilletarom View Post
..... 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.
__________________
NAV is offline   Reply With Quote
Old 11-02-2016, 01:24   #12
Registered User

Join Date: May 2013
Location: NSW, Australia
Boat: Richter 42
Posts: 883
Re: PlugIns and internationalisation

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
__________________
jongough is offline   Reply With Quote
Old 11-02-2016, 01:32   #13
NAV
Registered User

Join Date: Sep 2010
Location: Netherlands
Posts: 424
Re: PlugIns and internationalisation

Quote:
Originally Posted by jongough View Post
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?
__________________
NAV is offline   Reply With Quote
Old 11-02-2016, 01:46   #14
Registered User

Join Date: May 2013
Location: NSW, Australia
Boat: Richter 42
Posts: 883
Re: PlugIns and internationalisation

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

Quote:
Originally Posted by NAV View Post
Jon,
Just a simple (stupid?) question. Why can't OD use the same procedure as in OpenCPN?
__________________
jongough is offline   Reply With Quote
Old 13-02-2016, 06:05   #15
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,407
Re: PlugIns and internationalisation

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.
__________________

__________________
rgleason is offline   Reply With Quote
Reply

Tags
plug

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Plugins and outboard and laptop! Algarve OpenCPN 1 01-02-2014 20:00
Installing Debugger and VDR Plugins zodd OpenCPN 26 08-08-2013 08:40
PreBuild for OpenCPN Beta and Head with plugins (OpenSUSE) dominig OpenCPN 3 03-07-2013 06:04
Installateur de plugins, Install software for plugins. Gilletarom OpenCPN 3 30-04-2013 06:57
PlugIns: Fleet Code and GRIB kiltym OpenCPN 8 05-01-2013 05:53



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 15:57.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.