OpenCPN Version 2.1.0 Beta

[Netsurfer]

Thomas,

Originally Posted by cagney

Everyone, please check the News page on the wiki, about updating the wiki to reflect the new upcoming release. All contributors are encouraged to update their writings.

first of all there should be an updated outline for the OpenCPN Manual (see also my comment on the page, please). So users can simply add content to the (book)page and don't have to think about page names, structure, etc..
IMHO the anchor watch is an advanced feature ... . And pages like NMEA Sentences | Official OpenCPN Homepage are really interesting and surely have their right but do they really belong to the manual?

The reason why I am very much interested in this point is that I will appreciate it if the manual on opencpn.org could be the prototype for translated versions of the manual.

BTW: I am actually working on an offline help for OCPN and looking for a volunteer (whose mother-tongue is English) for shaping the texts.

Gunther

[idpnd]

BTW: I am actually working on an offline help for OCPN and looking for a volunteer (whose mother-tongue is English) for shaping the texts.

G., the consensus has been to get the wiki into such a state that it can be included as an offline help file. If you go into "print mode" you will find that the file makes excellent offline viewing in any browser. Since all modern O/S have browsers installed, this solution permits

- collaborative, real-time editing without requiring further software
- super simple updating from the evolving wiki by inclusion in CVS
- viewing on any user's pc

So perhaps we should not start further disparate help files and try and get the existing one in synch. I don't think the translations have to be replicas of the English version, the external ones (Spanish/French) should just be delivered in the same (wiki) format for offline inclusion.

[cagney]

Originally Posted by Netsurfer

Thomas,

first of all there should be an updated outline for the OpenCPN Manual (see also my comment on the page, please). So users can simply add content to the (book)page and don't have to think about page names, structure, etc..
IMHO the anchor watch is an advanced feature ... . And pages like NMEA Sentences | Official OpenCPN Homepage are really interesting and surely have their right but do they really belong to the manual?

The reason why I am very much interested in this point is that I will appreciate it if the manual on opencpn.org could be the prototype for translated versions of the manual.

BTW: I am actually working on an offline help for OCPN and looking for a volunteer (whose mother-tongue is English) for shaping the texts.

Gunther

Gunther, the relevant page can only be changed by manimaul. Please mail him your ideas: webmaster -at-opencpn.org
I agree that the content needs to be restructured for the new release, to make it logical and easy to contribute.
Meanwhile, there is no problem involved in actually going ahead and update the text. The restructuring can easily be done afterwards.

Thomas

[Netsurfer]

Originally Posted by idpnd

G., the consensus has been to get the wiki into such a state that it can be included as an offline help file.

Ah, OK. Didn't know that or read it somewhere.

If you go into "print mode" you will find that the file makes excellent offline viewing in any browser. Since all modern O/S have browsers installed, this solution permits

Same for an integrated help - see version 1.3.6

- collaborative, real-time editing without requiring further software
- super simple updating from the evolving wiki by inclusion in CVS
- viewing on any user's pc

Yes, that is all right and I am not saying in a word to not use the wiki for the complete documentation.
But imho there are also several disadvantages:

• huge overhead (downloading, installation, etc. aren't of any interest when already using/ working with the program)
• no version specific help
• no OS specific help (and also an overhead, see above)

And how about a (the) localized version(s)?

So perhaps we should not start further disparate help files and try and get the existing one in synch. I don't think the translations have to be replicas of the English version, the external ones (Spanish/French) should just be delivered in the same (wiki) format for offline inclusion.

Using one version (naturally the original one on opencpn.org) as a prototype has imho several advantages:

• simple to do as there have only the texts being translated and images replaced
• guarantees a certain completeness
• easy to see where updates are needed

IMO there are lots of other advantages, but before calling me a bellyacher ..., if the consensus is as described - OK.

Gunther

[idpnd]

This has been discussed..

http://www.cruisersforum.com/forums/...tml#post459962

http://www.cruisersforum.com/forums/...tml#post454706

But imho there are also several disadvantages:

huge overhead (downloading, installation, etc. aren't of any interest when already using/ working with the program)

This could be easily done by subdividing the wiki into components, whereby only the "how to use" bit would be included in the package

no version specific help

The wiki as drawn into CVS would always correspond to the exact version it is included in, thereby drastically reducing workload in packaging the right help file with the right version. The help file (and especially the section relevant to offline usage) would thus evolve alongside the programme.

no OS specific help (and also an overhead, see above)

If you want to ensure OS specific help via the traditional help file you would also have to customise- no problem with wiki as above. But I thought you don't want the "overhead" included anyway? I tend to agree - why have O/S specific info on how to get it running etc in the offline version.

And how about a (the) localized version(s)?

Currently there are to my knowledge help files in 4 languages and in 4 different formats. So if we were to agree on one.. Presto..

Sadly I'm far too stupid to work out how one would make sure the correct language help file is called depending on the active gui language..

Using one version (naturally the original one on opencpn.org) as a prototype has imho several advantages:

That's fine, I would just try and gather permission of the creators of the French/Spanish help edition to get something for inclusion in those languages soonish.

[Gilletarom]

Hello Dave,

W 210-613a Anchor watch.

1° OK, I understood but not immediately.

2° When I Desable anchor watch, the mark is always present but if I right clic on the mark,
a) the item "Delete the mark" does not appear.
b) the item "Set anchor watch" does not appear
c) It is not possible to place the boat on the mark with "Move the boat here".

d) For delete the mark, it is necessary to créeate an another mark and then "Delete all marks".

Can you resolve this ?


3° I thing that it is necessary, in the toolbox, to get out the choïce of the sound of "Toolbox"/"AIS" if this sound is the same that the sound used for anchor watch.



Best regards

Golletarom.

[Netsurfer]

Philipp,

let me sum up: The help content should be taken from the wiki -> so the format is HTML, right?

As long as we are not using any kind of collaborate script/program each localized help will be an individual part or stand-alone project, right?

So my conclusion is that it has to be delivered in the right format (HTML) and one needs to know, how the help file(s) will be integrated in the program (API).

AFAIS this is done in about.cpp:

void about::OnPageChange(wxNotebookEvent& event)
{
      int i = event.GetSelection();

      if(3 == i)                        // 3 is the index of "Help" page
      {
            wxString tips_locn = _T("doc/help.html");
            tips_locn.Prepend(*m_pDataLocn);

            if(!::wxFileExists(tips_locn))
            {
                  tips_locn = _T("doc/index.html");
                  tips_locn.Prepend(*m_pDataLocn);
            }

            if(::wxFileExists(tips_locn))
                  wxLaunchDefaultBrowser(tips_locn);

      }
}

I have no idea of C++ but it should be relatively easy to perform a check if a localized version (e.g. help_de_DE.html) exists. If so, call this file. If not use a fallback to the default (which can be named just help.html or help_en_US.html or anything else). Or just in case that a localized version isn't 100% complete integrate also a possibility to switch to the English one (which is assumed to be the most completed one).

Last but not least there are also some drawbacks on wikis. One e.g. is the inconsistency of the style of writing.

At the end it still needs some volunteers/ users who are willing to create a localized/ translated version in the right format. So it doesn't matter where it comes from, or does it? Use the wiki for the English version, but that doesn't mean that it has to be a wiki for other languages too.

IMHO creating a suitable help is

• very important for the program/ project
• a lot of work

So it might be questionable if there ever will be a localized help version even for the already translated languages. But if there are people who offer to create a loclized help, so why do not use it?

Gunther

[idpnd]

IMHO creating a suitable help is

• a lot of work

Absolutely! It is therefore vital to avoid duplication of effort and removing barriers to contributions. By having it always online & editable, you ensure that work can be done quickly and without bureaucracy by anyone who feels like it. There could of course be a process of approving and editing a certain wiki version for a release (such as 2.1.0+1) to ensure quality and consistency.

But if there are people who offer to create a loclized help, so why do not use it?

Yes, why not convert it to the same or a similar format if permission is granted. There would be an issue of where/how to host the other language wikis (FR and ES are hosted on free domains, your .de drupal wiki is technically similar).

By the way html can be localised in a semi-automatic fashion using omegat

[petermoree]

As OpenCPN is supposed to be a (from the user point of view) simple program. Maybe making a longer FAQ list instead of a *manual* is sufficient.

Example: In Tools / vector charts one can indicate

META objects (what are these)
Use SCAMIN (what is SCAMIN)

etc.

Peter

[Netsurfer]

First let me explain in short of what I am thinking for the integrated offline help file(s)):
As we already assume that the user have a browser installed on his system, so I am thinking about an offline version which offers some kind of "comfort" and interactivity if Javascript is also available (which is most presumable). So it can respect e.g. the actual screen size (thinking of the users on Netbooks and other small screens).

The scaffold/ base frame could be identical for all versions (language independent). Some basic strings and the name of integrated images can be stored in separate files so that they are easy to translate/ exchange.

All the rest (the explaination text/ content) is completly different anyway. So this might come from whatever source (e.g. from a wiki).

Originally Posted by idpnd

Absolutely! It is therefore vital to avoid duplication of effort and removing barriers to contributions. By having it always online & editable, you ensure that work can be done quickly and without bureaucracy by anyone who feels like it. There could of course be a process of approving and editing a certain wiki version for a release (such as 2.1.0+1) to ensure quality and consistency.

Same as Dave is doing for each release the help file(s) need(s) to be updated and maintainded as well. But the same is true for a/ the wiki.

Yes, why not convert it to the same or a similar format if permission is granted. There would be an issue of where/how to host the other language wikis (FR and ES are hosted on free domains, your .de drupal wiki is technically similar).

That is one of the main reasons why I set up a Drupal website as well. But once again: as long as there is no collaborate script it doesn't matter at all . And as nearly the whole content is different such a script wouldn't make much sense in the end. Only advantage I see is that one can easily 'copy' the structure.

An alternative may be to isolate the help-wiki part from the rest and make it available by subdomains like:

http://help.en.opencpn.org/
http://help.fr.opencpn.org/
http://help.de.opencpn.org/
...

Doing it this way will ensure that there is the same "infrastructure" for each language.

But I am not quite sure if this would really be a better solution. As all wiki projects show that I know it is extremely hard to find contributors. And if you don't want the wiki to grow uncontrolled in each direction you have to target certain things or to set up a base frame.

So maintaining an individual and separate help version (maybe with one contact person for Dave for each language version) isn' that wrong. And just to say it clearly: Of course can the content for these help file(s) derive from a wiki or every other source.

By the way html can be localised in a semi-automatic fashion using omegat

Yes, this may help or not ..., depends on the user and his preferences.

When you use HTML as your base format there are a few possibilities for localization:

1. use .ini files (needs PHP support, therefore there have to be a local server with PHP installed on each system if you want to work it offline)
2. other server side techniques (same issue as with 1.)
3. use Javascript to be able to work with variables

The basic problem with HTML sites which should be offline available is that HTML pages are static by design.

Originally Posted by idpnd

This has been discussed..

BTW: IMHO now we are discussing the topic (even in the wrong thread as I wanted to hear and discuss the different meanings, approaches, etc. in http://www.cruisersforum.com/forums/...cpn-41045.html).

Gunther

[Netsurfer]

Peter,

Originally Posted by petermoree

As OpenCPN is supposed to be a (from the user point of view) simple program. Maybe making a longer FAQ list instead of a *manual* is sufficient.

Simple or not depends on the individual skills & knowledge.
I know (and administer their PCs for them) at least three skippers (each > 65) who aren't familiar with PCs at all. And when they started sailing no one was talking about GPS, AIS, ENC, etc.
And also regarding the questions in the German Community forum I cannot agree with you .

Example: In Tools / vector charts one can indicate

META objects (what are these)
Use SCAMIN (what is SCAMIN)

This is more or less a "Glossary" (see Glossar | OpenCPN.de) which of course can be integrated wherever it fits.

BTW: Do you know a good explanation for META objects or a definition what they are? Or more precise: Which objects belong to the META objects?

Gunther

[Ptizef]

Hi Dave

Back with a limited wifi connection
Thanks for the new beta
one point detected on 611 but still occurring in 613b
Create two routes with a common point (using "use nearby waypoint")
With route manager , set one of them invisible
Right click on the common point on the still visible route : The context menu get is wrong (see shot the context menu I get even the wpt is selected and highlighted)In fact I get the general context menu but nothing about Wpt menu

Best regards
Jean Pierre

[Gilletarom]

Hello, Bonjour,

Originally Posted by idpnd

Yes, why not convert it to the same or a similar format if permission is granted. There would be an issue of where/how to host the other language wikis (FR and ES are hosted on free domains, your .de drupal wiki is technically similar).

I am Gilletarom. It is not my name but on the web, if you please, I prefer to keep my pseudonym.

I do not understand perfectly everything that you write abouit the help for OpenCPN. But as I participate in the group who works on the french tutorial. So, I allow myself to invite me in your conversation.

One must know that:
- Five persons ' group was in place by chance after a long thread on OpenCPN in a French forum. We did not know front noël 2009 for us. - We do not know ourselves much not any more. - Two amongst us navigate in the east of Mediterranean Sea, another in the ocean Indian, another is at Marseille in the south of France and as for me same I live in Paris 's region. Among us, 3 persons are retirees. In our group, I am this one who navigated the least.

- After one very important work, (37 html pages) which was put online under html format and under pdf format, the group is currently instead in "stand by." I ensure alone the continuity pending that the buddies deliver themselves to the work. But risk us to no longer be than two at the next autumn. - The html format (ICI) only is constituted of html pages. There is not database of type mysql and there is no page incorporating PHP.

- This format imposes to know to make pages in html. Thus it limits much too much the number of marine which could work to our group. I regret thus that we did not use CMS (Content Managing System ) as it is the case for the site opencpn.org.

Questions:
He would be possible for each of the editors of the others wikis on OpenCPN to speak us one little of the manner of which they arrived the and their manner work?

Cordially

Gilletarom


Note : Can be one must create thead to not clutter the thread on the 210 up with this subject.




------ en Français :

Je suis Gilletarom. Ce n'est pas mon nom mais sur le web, je préfère garder mon pseudonyme.

Je ne comprends pas parfaitement tout ce que vous écrivez sur la mise en place d'une aide pour OpenCPN. Mais comme je fais parti du groupe qui travaille sur le tutoriel en Français, je me permets de m'inviter dans votre conversation.

Il faut savoir que :
- Notre groupe de cinq personnes s'est mis en place par hasard à la suite d'un long fil sur OpenCPN dans un forum français Nous ne nous connaissions pas avant noël 2009.
- Nous ne nous connaissons pas beaucoup plus maintenant.
- Deux d'entre nous naviguent en Méditerranée, un autre dans l'océan indien, un autre est à Marseille dans le sud de la France et moi même je vis dans la région de Paris. Parmi nous, 3 personnes sont des retraités. Dans notre groupe, je suis celui qui a navigué le moins.
- Après un très important travail, (37 pages html) qui a été mis en ligne sous forme html et sous forme pdf, le groupe est actuellement plutôt en "stand by". J'assure seul la continuité en attendant que les copains se remettent à l'ouvrage. Mais nous risquons de ne plus être que deux à l'automne prochain.
- Le format html ( ICI ) n'est constitué que de pages html. Il n'y a pas de base de données de type mysql et il n'y a pas de page contenant du PHP.

Ce format impose de savoir faire des pages en html. Donc cela limite beaucoup trop le nombre de marins qui pourraient venir travailler dans notre groupe. Je regrette donc que nous n'ayons pas utilisé un CMS (Content Managing System ou système de gestion de contenu) comme c'est le cas pour le site opencpn.org.

Questions :
Serait il pssible que chacun des gestionnaires des autres wiki sur OpenCPN nous parle un peu de la façon dont ils en sont arrivés la et de leur façon de travailler ?

Cordialement

Gilletarom.

Nota bene : Peut être faut il créer un fil pour ne pas encombrer le fil sur la 210 avec ce sujet.

[Ptizef]

Hi Dave

Two points :
1) When in quilt mode and two chart types (for example for me CM93 and BSB )
If I click on a control bar that lead to change the type of chart , the quilt mode is immediately deactivated . This is a new behavior , I don't know if it's a bug but it's not user friendly
2) A very good idea , the AIS targets list but I get some curious targets with incoherent values ( Sog = 555 ... ) see shots attached
Best regards
Jean Pierre

[idpnd]

Originally Posted by Gilletarom

Nota bene : Peut être faut il créer un fil pour ne pas encombrer le fil sur la 210 avec ce sujet.

http://www.cruisersforum.com/forums/...cpn-41045.html