Lazarus

Miscellaneous => Translations => Topic started by: dbannon on April 22, 2019, 02:23:58 am

Title: I18N and maintaining PO files
Post by: dbannon on April 22, 2019, 02:23:58 am
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
Title: Re: I18N and maintaining PO files
Post by: dsiders on April 22, 2019, 03:33:13 am
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.
Title: Re: I18N and maintaining PO files
Post by: lainz on April 22, 2019, 03:43:51 am
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.
Title: Re: I18N and maintaining PO files
Post by: dsiders on April 22, 2019, 03:54:51 am
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.
Title: Re: I18N and maintaining PO files
Post by: lainz on April 22, 2019, 03:57:44 am
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.
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 22, 2019, 08:19:11 am
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
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 22, 2019, 01:34:51 pm
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 ?


Davo


           
Title: Re: I18N and maintaining PO files
Post by: wp on April 22, 2019, 03:55:28 pm
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".
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 23, 2019, 02:26:39 am
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 ?  )
Title: Re: I18N and maintaining PO files
Post by: Thaddy on April 23, 2019, 07:38:26 am
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.
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 23, 2019, 10:05:50 am
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
Title: Re: I18N and maintaining PO files
Post by: Thaddy on April 23, 2019, 10:22:41 am
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...
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 23, 2019, 10:40:38 am
Quote
...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 
 
Title: Re: I18N and maintaining PO files
Post by: marcov on April 23, 2019, 10:55:58 am
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)
Title: Re: I18N and maintaining PO files
Post by: wp on April 23, 2019, 11:03:37 am
In the attachment I am posting a simple demo supporting translations, and it works as I would expect it.
Title: Re: I18N and maintaining PO files
Post by: marcov on April 23, 2019, 11:16:57 am
In my own dxgettext based windows only Delphi app, I have a combobox like Lazarus but with some additional options:

1. System default (whatever the default language detection yields, fall back to builtin if not detected)
2. none(no translation, easy to check what the key text is for a certain control)
3. a list of detected .mo files  (besides files on disk, it also checks a list of internal Windows resources), so the user can override.

The configuration setting is initialized on system default, and also reverts to that if the configuration contains a language for which the mo is no longer available. Changing the combobox is only active after restart. There are also some hacks to fall back from similar locales  (like map all german and french variants to the core french, since we don't really provide dialect translations).

One of the reasons is that the same app is sometimes used in multiple locations, with technical/lab staff preferring english(since they often receive betas and directly communicate with us), and the normal work floor in local language. But it is the same company so they all have the same localized windows.

Title: Re: I18N and maintaining PO files
Post by: Thaddy on April 23, 2019, 12:44:18 pm
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)
Using the format alone counts as standard to me.... But it is largely a free world. I expect things to work, preferably in similar manners.
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 23, 2019, 12:46:44 pm
Yep, its no more that a couple of line to fix. Just needs (in LCLTranslator, FindLocalFileName()  )
Code: Pascal  [Select][+][-]
  1. if Application.HasOption('l', 'lang') then
  2.   lang := Application.GetOptionValue('l', 'lang')
  3. else begin
  4.      //
  5.      // do existing stuff that detects space separated syntax
  6.      //
  7. end;

Oh, and wp, the '=' syntax is the GNU recommended model, its just they accepts people do it with a space sometimes.

I'll put in a bug report with a patch.

Davo
Title: Re: I18N and maintaining PO files
Post by: dbannon on April 23, 2019, 02:07:11 pm
https://bugs.freepascal.org/view.php?id=35432

Davo
TinyPortal © 2005-2018