I18N and maintaining PO files

[dbannon]

Totally new space to me, please be gentle ...

Someone has offfered to provide a Spanish translation for my app, I long ago turned on I18N but know no more than what I have read on the wiki.

If this person sends me back a PO file based on my current snapshot, and I then add a new term somewhere, and build my app, that new term appears in my (default, english) po file but is not merged into the Spanish one. Its clearly impractical for him to start anew for every release. I guess there is a process that merges new or changed entries from the default PO file to existing translations ?

If its not Lazarus that does that, is it (eg) poedit ?  What approach to people recommend please ?

Davo

[dsiders]

Totally new space to me, please be gentle ...

Someone has offfered to provide a Spanish translation for my app, I long ago turned on I18N but know no more than what I have read on the wiki.

If this person sends me back a PO file based on my current snapshot, and I then add a new term somewhere, and build my app, that new term appears in my (default, english) po file but is not merged into the Spanish one. Its clearly impractical for him to start anew for every release. I guess there is a process that merges new or changed entries from the default PO file to existing translations ?

If its not Lazarus that does that, is it (eg) poedit ?  What approach to people recommend please ?

Davo

The sync you're looking for doesn't happen automatically. There is a program in ./tools/updatepofiles.pas that can be used to sync a resource file and its .pot file (that's the translation template) and any files generated from that template. You still have to submit the .pot for translation again to get translated strings for each language/locale.

Hope that helps.

[lainz]

Actually if you rebuild your application (Compile > Build) the po file gets updated with the new terms. Just send that back and poedit will show only the new entries to translate.

[dsiders]

Actually if you rebuild your application (Compile > Build) the po file gets updated with the new terms.

I've never seen that happen after a Build.

But I did just discover the Force update PO Files on next build button in Project options. You learn something new every day.

[lainz]

Yes, it must be from that menu entry, not a normal hit on the play button, I don't know the reason BTW.

Edit: the right name of the menu is Run > Build.

[dbannon]

OK, great answers folks !

As stated, tick the checkbox dsiders mentions and, lo !  an old translation file I had in there has been updated with -

1. new stuff I added since it was done
2. unused entries removed.
3. Unchanged entries have kept their translation.

Hmm, when looking at the updated Spanish po file, I note that some entries in POEdit are orange in colour, I'm unsure why. Firstly we have new entries that don't have a translation, then we have some with a translation in black and some in orange, wonder what the difference is ?

I'll play a little and update the wiki as I work it out.

How good is this IDE ?  And how good is this forum !

Davo

[dbannon]

Hmm, no, not working.   The I18N stuff in my app that is.  So, made a simple example and thats not working either.  I made a tiny app that includes -

Code: Pascal  [Select][+][-]

1. uses LCLTranslator;
2.  
3. procedure TForm1.Button1Click(Sender: TObject);
4. begin
5.     SetDefaultLang('es', 'locale', true);
6.     memo1.append('Country Code ' + Copy(GetEnvironmentVariable('LC_CTYPE'), 1, 2));
7. end;

Turned I18N on in project options, pointed it to a directory called locale and built. I then used poedit to make a new Spanish version, called project1.es_ES.po and a matching project1.es_ES.mo containing some fake Spanish translations.

I tried setting a run parameter in the ide of --lang=es    and also launched from linux command line also with the same switch. But all I see is english captions. 

So I used strace to see what files were being opened or attempted. No sign of the app making any attempt to open a file called project1.es_ES.mo or look in a directory called locale other than /usr/share/locale

Note I also looked at the LC_CTYPE var and thats always blank. And I tried setting language to es in the code. User both DefaultTranslator and LCLTranslator (only later allow use of SetDefaultLang() ). Appears to me the switch, "--lang=es" is being ignored.

Just what have I missed ?

• I use lcltranslator (or defaulttranslator), 
• I tick the Project->ProjectOptions->i18N , enable i18N
• I use a runtime commandline switch    --lang=es    and      --lang es     (as suggested by wiki page).
• I tried putting the necessary files in a directory called locale and languages

Davo


           

[wp]

new Spanish version, called project1.es_ES.po [...] I tried setting a run parameter in the ide of --lang=es         

These settings don't match: either call the translation file "project1.es.po" or ask for language "--lang=es_ES".

[dbannon]

Thanks WP, I did try both combinations, no difference.

I have been browsing through LCLTranslator and its pretty weird !

Firstly, we have -

for i := 1 to Paramcount - 1 do begin

So, if the --lang=es is only parameter, we don't do the subsequent test.
Next, if instead use we use a space rather than an '=',   --lang es  we do pick it up.
It then calls the helper, GetLocaleFileName(Lang, LCExt, Dir); that tries almost every possible combination of short and long locale codes and directory structure.

About the only combination it does not try is the one documented in the wiki, that is  ./locale/project1.es.mo

Now, I am happy to update the wiki but am not really sure if that is the correct thing to do. I don't for the life of me understand why we have to use the space between long switch and its parameter, but thats clearly what the code wants.

Code: Pascal  [Select][+][-]

1. --lang es        // works but is inconsistent with normal lazarus model
2. --lang=es      // does not work, but, I believe should.
3.  
4. -les                // does not work
5. -l es               // does work
6.  

So, rather than fixing the docs, should I fix the code ?  Are there people depending on existing model ?

There are two separate issues going on here, the formt of the switch AND the location of the mo file.

Davo

(sorry for edit, accidental early post ...)

(Another edit : it does in fact find  ./locale/project1.es.mo but only if it has not found project1.po first. If it finds that, and thats likely to be your primary language one, in my case, English, it uses it. So, it appears to not have changed. So, important, don't keep po files in ./locale   I think searching for ./locale/project1.po is a mistake, I cannot imagine why someone would want that ?  )

[Thaddy]

I would not change anything.
The options style is simply GNU gettext format. (even generic Linux/Unix options format)
It would be very strange if the options would differ from GNU gettext...
https://www.gnu.org/software/gettext/

Options are always a point for discussion, but in this case: keep the GNU syntax.
I for one use it not only for Lazarus but for many other purposes.
It would be very unnatural if the syntax starts to differ between applications.

[dbannon]

At great personal risk, I am afraid I must disagree with you Thaddy.

The FPC/Lazarus approach seems to be --long-option=somevalue.   Application.GetOptionValue() for example will not return a long option's value if its seperated with a space instead of an equals sign. CheckOptions() returns an error if we tell it a long option should have a value.

Using a space, Application.GetNonOptions() gives an exception if we tell it a long option should have a value. If we lie and say it should not return a value, GetNoOptions() returns the (space separated) value as a non-option parameter.

GNU  https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html, says long options should use the equals sign if they return a value.

I do agree its very common practice to use a space, the C getopt will use it but its not the way we normally do it here in Lazarus land. Lazarus itself takes '='.   Think of --pcp=somepath ?

I do think it would be a horrible mix if I was to tell my users that some options to the app require an equals and some require a space !

Its a pretty simple change to have DefaultTranslator accept either an equals or a space and help pages would look a lot prettier !

Davo

[Thaddy]

At great personal risk, I am afraid I must disagree with you Thaddy.

People who actually know me can verify I do not cause any physical nor psychological harm, except the occasional proud when somebody is wrong.
The point I am making is that there are standards. You should adhere to standards. Not to whatever seems comfortable on windows only...

[dbannon]

...Not to whatever seems comfortable on windows only...

Wow, I expected a serve but not to that extent. To suggest I'm a Windows user ....

For your information, been a full time Linux user most of my computing life. Managed several Linux based machines that were listed on the Top500. And a (sort of) Linux machine that was the biggest system south of the Tropic of Cancer.

But you are right, standards are important. I have sat on several standards establishing bodies and one thing I know is we can always squeeze in one more standard !

Seriously, (and the above is not meant seriously) if you care to re-read my last post, you will see I was basing my argument solely on standards. The standard way of doing command line options in the Lazarus world. The standard enforced by FPC/Lazarus tools. The standard recommended by GNU - er, where have I gone wrong ?

Davo 
 

[marcov]

You should adhere to standards.

There is no standard. libgettext intercepts params on unix, but we don't use libgettext, so our parameters work differently. (and e.g. Lazarus allows setting language persistent without messing with environment variables or cmdline parameters)

[wp]

In the attachment I am posting a simple demo supporting translations, and it works as I would expect it.

• The language on my system is German --> when I run the program as it is the GUI comes up in German. This is because unit "DefaultTranslator" is included in "uses" (it contains initialization code to determine the system language). Without it it would select English, the original language of the demo program.
• When I want the program to be in French I can use commandline parameters: "--lang fr" or "-l fr" (without quotes) (Indeed, having to switch from the Lazarus command line parameter syntax to the GNU syntax here is confusing. Why don't you write a bug report/feature request and let Maxim Ganetzky decide who maintains the language subsystem of Lazarus?)
• Requesting a Spanish translation by clicking on the button works, too. Note that the Spanish translation file is "project1.es_ES.po" here, and therefore, the language code to be used in the SetDefaultLang call must be "es_ES".