Recent

Author Topic: localization problem  (Read 6344 times)

djdjdjole

  • Full Member
  • ***
  • Posts: 101
localization problem
« on: August 02, 2016, 08:38:27 pm »
I have relatively large project written in Lazarus 1.6 (OS= Windows 10 64-bit). I tried localization on some example - two form project and everything go well. However when trying the same with my "big" project, compiler generated .po file only has resource strings without any buttons, forms, ... that are part of my application. I included LCLTranslator unit in my main unit the same way which worked in my simple project. No need to mention that I checked i18 and so on... (same like I did before).
Any help ?

wp

  • Hero Member
  • *****
  • Posts: 11853
Re: localization problem
« Reply #1 on: August 02, 2016, 09:51:12 pm »
Did you check "Create/update .po file when saving a lfm file"?

Did you re-save every lfm file when you started the translation? Maybe you must apply some minor change to the form to get it really written anew.

Is there a unique location of the po files? I already had cases where there were two folders, one in the source folder and one in the bin folder for the exe. This is not good because you must always update one folder with the contents of the other one. If you forget this, "mysteriously" the po files will no longer be up-to-date.

djdjdjole

  • Full Member
  • ***
  • Posts: 101
Re: localization problem
« Reply #2 on: August 03, 2016, 09:28:59 am »
Thanks for reply, however i had some new issues emerged regarding my translation. The only place I put LCLTranslator unit was in my main form unit, according to step by step tutorial. However when placing it in two more forms (for beginning only), I received MOST of the components properties (of these forms) in generated .po file.
Still, for example StringGrid Columns property (Title/Caption) was not offered for translation in .po file.

Thanks

djdjdjole

  • Full Member
  • ***
  • Posts: 101
Re: localization problem
« Reply #3 on: August 03, 2016, 09:52:25 am »
I forgot to reply to wp member that I checked "Create/update .po file when saving a lfm file".
Few times I tried compile after compile, only deleting .po file in between but sometimes .po file even wasn't being generated.
Regarding folder location question, my project has main folder (pas, lfm, lpr, ...files), lib folder (ppu, lfm (again ?), ...files), backup folder and (only one) folder for .po file.

Thanks

wp

  • Hero Member
  • *****
  • Posts: 11853
Re: localization problem
« Reply #4 on: August 03, 2016, 10:34:21 am »
What is your Lazarus version? I can confirm that grid titles are missing from the po file for Laz 1.6 (both release and fixes), but they are correctly exported with Laz trunk. If you use trunk there was a change in the localization resource files. You may have to execute "Project" / "Resave forms with enabled i18n" to convert from the old to the new resource files (lrt to lrj).

Is there a way that you can create a demo project out of your "big" application which shows the issue?
« Last Edit: August 03, 2016, 10:38:54 am by wp »

djdjdjole

  • Full Member
  • ***
  • Posts: 101
Re: localization problem
« Reply #5 on: August 03, 2016, 11:36:13 am »
My Lazarus version is 1.6. I didn't try translation with trunk version, which I will probably do.
Regarding your question of mini demo version I consider it not to be so simple. There are around 40 units, most of them interrelated. Also I guess, I should have some kind of permission from my superiors to release some demo version. However I am grateful for your efforts and aware that it would be my benefit to try so.

wp

  • Hero Member
  • *****
  • Posts: 11853
Re: localization problem
« Reply #6 on: August 03, 2016, 02:26:07 pm »
Don't forget to backup your work before you switch to trunk. Some components may add new properties. This will cause errors when you switch back to 1.6.

I don't know if this is true, but probably automatic po generation does not work if a unit is not found in the project. --> Add all units to the project, do not rely on the search path alone.

If some of these 40 units are grouped in separate packages then these packages must have i18n enabled as well.

djdjdjole

  • Full Member
  • ***
  • Posts: 101
Re: localization problem
« Reply #7 on: August 04, 2016, 04:14:26 pm »
Installed trunk version and StringGrid titles is now offered for translation. However some forms (with their subcomponents) are not stated in .po file, even if I explicitelly put LCLTranslator unit in them (at first it was only quoted in main form unit).
I've also used "Resave forms with enabled i18n". My .po file is 1294 bytes in size, although I have presently more then 50 units with at least 10 forms, which I expect would "require" bigger file.
Last observation- I added new (dummy) form to application and suddenly some forms appear (in .po), that was not here before this addition.

wp

  • Hero Member
  • *****
  • Posts: 11853
Re: localization problem
« Reply #8 on: August 05, 2016, 12:31:56 am »
I doubt that putting LCLTranslator can trigger inclusion of a unit into a po files.

Unfortunately, I am not an expert on this field. Many core developers do not read the forum, therefore, I'd ask you to post your question on the Lazarus mailing list where the chance increases that a knowledgable person will read it. (For posting to the mailing list you must register at http://lists.lazarus-ide.org/mailman/listinfo/lazarus).

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: localization problem
« Reply #9 on: August 05, 2016, 01:28:50 am »
Saving the form really doesn't update the .po file.

You need to compile the entire project in order to update the forms in the .po, not run (F9). Use Run > Compile or Run > Build to update all forms.

Also the unit of the form must be added to the project or it will not work.

I've tested personally all of the things I'm saying here.

To ensure all the stuff is inside the .po file is to translate them and run the translated version of your program.

It some elements are not in the po file, you can add resourcestrings and manually change the strings where needed.

djdjdjole

  • Full Member
  • ***
  • Posts: 101
Re: localization problem
« Reply #10 on: August 05, 2016, 08:26:18 am »
Thanks for your replies and advices. I already considered (but not tried yet) to include some component properties into .po file, manually. At least there is always an option to run translation in "programmers own way". I will post my observations if something new emerge relating this issue.

Thanks

djdjdjole

  • Full Member
  • ***
  • Posts: 101
Re: localization problem
« Reply #11 on: August 05, 2016, 12:57:24 pm »
I can confirm that manual addition of some property in .po file, indeed helps. I've done it over some button caption property, which was not initially quoted in auto-generated .po file.

coliv_aja

  • New Member
  • *
  • Posts: 38
Re: localization problem
« Reply #12 on: August 05, 2016, 07:53:21 pm »
po file was created from rst/rsj/lrt/lrj file. You need to trigger the creation of this file if there is none.
For forms, you have to make sure the forms unit is in project inspector.
If there is no lrt/lrj file for some forms, you can trigger it by make a small changes to the forms, like changing caption, then save the forms. The creation only happen when saving modified forms. Then you can change back whatever you change before.
In lazarus trunk there "Resave forms with enabled i18n" under "Project" menu to force the creation of this file.
« Last Edit: August 05, 2016, 08:03:27 pm by coliv_aja »

 

TinyPortal © 2005-2018