Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-09

LazDataDesktop duplicated language translation files

9 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marcelo Borges de Paula

Hello everyone,

After revision 21675, when LazDataDesktop was updated, the language translations file is duplicated. I think this happened because "option i18n" is enabled. This created .po files with project name. The correct files is lazdatadeskstr.* that was generated from lazdatadeskstr.pas Can someone with access to svn repository could simply correct this or you need me to create a bug report?

Thanks,

Marcelo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090912/83805ca5/attachment.html>

Mattias Gaertner
to Marcelo Borges de Paula
Show quoted text 8 lines
Hello everyone, After revision 21675, when LazDataDesktop was updated, the language translations file is duplicated. I think this happened because "option i18n" is enabled. This created .po files with project name. The correct files is lazdatadeskstr.* that was generated from lazdatadeskstr.pas Can someone with access to svn repository could simply correct this or you need me to create a bug report?

Are you sure, that lazdatadeskstr.po is the right one? The lazdatadesktop.ru.po seems to have more strings.

Mattias

Michael Van Canneyt
to Mattias Gaertner
Mattias Gaertner wrote 14 lines
On Sat, 12 Sep 2009 22:51:24 -0300 "Marcelo Borges de Paula" wrote: > Hello everyone, > > After revision 21675, when LazDataDesktop was updated, the language > translations file is duplicated. I think this happened because > "option i18n" is enabled. This created .po files with project name. > The correct files is lazdatadeskstr.* that was generated from > lazdatadeskstr.pas Can someone with access to svn repository could > simply correct this or you need me to create a bug report? Are you sure, that lazdatadeskstr.po is the right one? The lazdatadesktop.ru.po seems to have more strings.

The lazdatadesktop.* files are the new ones to use, and as far as I know currently, the lazdatadeskstr.* ones should disappear.

Unfortunately, I don't understand the consequences of the "option i18n", so I am kind of blindly applying patches I get from people. Can someone enlighten me ?

Michael.

Maxim Ganetsky
to Marcelo Borges de Paula: After revision 21675, when LazDataDesktop was updated, the language translations file is…

Marcelo Borges de Paula ?????:

Show quoted text 10 lines
Hello everyone, After revision 21675, when LazDataDesktop was updated, the language translations file is duplicated. I think this happened because "option i18n" is enabled. This created .po files with project name. The correct files is lazdatadeskstr.* that was generated from lazdatadeskstr.pas Can someone with access to svn repository could simply correct this or you need me to create a bug report?

I already asked Michael to remove duplicate files.

Renaming was needed to allow IDE to update translations during project compilation. As you can see, lazdatadesktop*.po files include all your previous translated strings plus some extra not translated ones, so IDE appears to update translations correctly. IMO we need to remove lazdatadeskstr*.po files.

Best regards, Maxim Ganetsky mailto:
Marcelo Borges de Paula

Hello again,

The right files was lazdatadeskstr.*. It was generated from lazdatadeskstr.rst. When "i18n option" is enabled, IDE creates correspodent language files with project name in target language directory. Similar to what happens with package, the resources are generated from all files in project. In this case, all resource strings was moved in recent updated to "lazdatadeskstr.pas". So any improvements may alter this file to include new resources. After that, the developer must use tool "updatepofiles" to update existent .po files from lazdatadeskstr.rst. With this method no files are generated automatically (.po or .lrt), and there is no need to mantain the "i18n option" enabled. Take a look in "localize.bat" or "localize.sh" in Lazarus root.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090913/e5744b00/attachment.html>

Maxim Ganetsky
to Marcelo Borges de Paula

Marcelo Borges de Paula ?????:

Show quoted text 5 lines
Hello again, The right files was lazdatadeskstr.*. It was generated from lazdatadeskstr.rst.

If you look inside new PO files you will see that resource strings are still there, though these files are bigger then they need to be (some extra strings seem to be taken from LRT file).

Show quoted text 6 lines
When "i18n option" is enabled, IDE creates correspodent language files with project name in target language directory. Similar to what happens with package, the resources are generated from all files in project. In this case, all resource strings was moved in recent updated to "lazdatadeskstr.pas". So any improvements may alter this file to include new resources.

New resources still can be included to lazdatadeskstr.pas and PO files will be updated correctly with them.

Show quoted text 5 lines
After that, the developer must use tool "updatepofiles" to update existent .po files from lazdatadeskstr.rst. With this method no files are generated automatically (.po or .lrt), and there is no need to mantain the "i18n option" enabled. Take a look in "localize.bat" or "localize.sh" in Lazarus root.

You don't need to do extra steps to update localization now, what's wrong with this?

Best regards, Maxim Ganetsky mailto:
Marcelo Borges de Paula

Well, before adventured myself, helping Lazarus with translations, i did some research about how things were done in this matter. Seems that majority used this method, so i followed it.

Some considerations:

- Using "i18n option enabled" you have two different behavior of IDE automatic language generation:
1) Projects: IDE generated .po file with project?s name, which concentrates all resources from all files in project.
2) Packages: For every form in package, a correspondent file (.lrt) is generated and a correspondent file (.po) file is generated. This could end with a bunch of files in language directory, each one requiring translation. Example: If a package generates 4 language files, for each language you got 4 files. So if you have 10 supported languages.....

- Concentrate all resources in one .pas file gives you more centralized control over that strings. This is not the case with "i18n", since IDE can generate resources from .pas where they are declared. So you know that that string exists, but you will need to do a search in files to locate it. This is more simply to do in one file.

- I tought that having one method in mind is better than having to remember that for projects i need to do one way, and with packages another way.

Maybe it?s a good opportunity to discuss some standards about this matter. There is a lot to do in this field. Reach a common sense may avoid big headaches in future.

Marcelo.

Show quoted text 29 lines
Marcelo Borges de Paula ?????: > > Hello again, > > The right files was lazdatadeskstr.*. It was generated from > lazdatadeskstr.rst. If you look inside new PO files you will see that resource strings are still there, though these files are bigger then they need to be (some extra strings seem to be taken from LRT file). > When "i18n option" is enabled, IDE creates correspodent language files > with project name in target language directory. Similar to what happens > with package, the resources are generated from all files in project. > In this case, all resource strings was moved in recent updated to > "lazdatadeskstr.pas". So any improvements may alter this file to include > new resources. New resources still can be included to lazdatadeskstr.pas and PO files will be updated correctly with them. > After that, the developer must use tool "updatepofiles" to update > existent .po files from lazdatadeskstr.rst. With this method no files > are generated automatically (.po or .lrt), and there is no need to > mantain the "i18n option" enabled. > Take a look in "localize.bat" or "localize.sh" in Lazarus root. You don't need to do extra steps to update localization now, what's wrong with this?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090913/32813c6e/attachment-0001.html>

Mattias Gaertner
to Marcelo Borges de Paula
Show quoted text 22 lines
Well, before adventured myself, helping Lazarus with translations, i did some research about how things were done in this matter. Seems that majority used this method, so i followed it. Some considerations: - Using "i18n option enabled" you have two different behavior of IDE automatic language generation: 1) Projects: IDE generated .po file with project?s name, which concentrates all resources from all files in project. 2) Packages: For every form in package, a correspondent file (.lrt) is generated and a correspondent file (.po) file is generated. This could end with a bunch of files in language directory, each one requiring translation. Example: If a package generates 4 language files, for each language you got 4 files. So if you have 10 supported languages..... - Concentrate all resources in one .pas file gives you more centralized control over that strings. This is not the case with "i18n", since IDE can generate resources from .pas where they are declared. So you know that that string exists, but you will need to do a search in files to locate it. This is more simply to do in one file.

It is planned to add an option to gather all resourcestrings in one po file for each package/project.

Show quoted text 7 lines
- I tought that having one method in mind is better than having to remember that for projects i need to do one way, and with packages another way. Maybe it?s a good opportunity to discuss some standards about this matter. There is a lot to do in this field. Reach a common sense may avoid big headaches in future.

Mattias

Marcelo Borges de Paula

Yes, i know. Saw it on wiki.
But what to do in the meantime ?
We should stop what we are doing in this matter until that got implemented ? Or we should encounter an intermediary rule until then?

Marcelo.

Show quoted text 22 lines
Well, before adventured myself, helping Lazarus with translations, i did some research about how things were done in this matter. Seems that majority used this method, so i followed it. Some considerations: - Using "i18n option enabled" you have two different behavior of IDE automatic language generation: 1) Projects: IDE generated .po file with project?s name, which concentrates all resources from all files in project. 2) Packages: For every form in package, a correspondent file (.lrt) is generated and a correspondent file (.po) file is generated. This could end with a bunch of files in language directory, each one requiring translation. Example: If a package generates 4 language files, for each language you got 4 files. So if you have 10 supported languages..... - Concentrate all resources in one .pas file gives you more centralized control over that strings. This is not the case with "i18n", since IDE can generate resources from .pas where they are declared. So you know that that string exists, but you will need to do a search in files to locate it. This is more simply to do in one file.

It is planned to add an option to gather all resourcestrings in one po file for each package/project.

Show quoted text 7 lines
- I tought that having one method in mind is better than having to remember that for projects i need to do one way, and with packages another way. Maybe it?s a good opportunity to discuss some standards about this matter. There is a lot to do in this field. Reach a common sense may avoid big headaches in future.

Mattias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090913/4739b81a/attachment.html>