Could somebody please explain what happens when there is #13#10 in a resource string.

See issue
http://bugs.freepascal.org/view.php?id=26343
and a note:
http://bugs.freepascal.org/view.php?id=26343#c75738

It is converted to \n in .po file strings.
However Format() does not convert \n. How can it work? I will do more experiments later today.

Regards,
Juha

Format should not convert \n. This is the job of the .po reader.

Michael.

In my opinion, ti should be solved... I am adding \n into po files translations of licences, where the new line is needed. But If I need linebreak in resourcestring, it's not really comfortable to replace every linebreak with %s and Format() param - it decreases readablity of file... In my apps, I am using gettext ported from some gnu library for delphi, where translation is done with _('text to translate') function (which accepts Format() params too) and there is no problem with \n in text... Another advantage is that I don't have to look for resourcestring and check if it is not used in another part of application, but I have to use external tool to regenerate translations....

V?clav Val??ek

Dne 17.6.2014 07:36, Juha Manninen napsal(a):

As Michael wrote Format() does not need to deal with it. The translated value of the resourcestring constant should already contain the correct line ending and thus the .po-reader needs to handle this when it sets up the translated strings.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140617/1577cc8e/attachment.html>

Format should not convert \n. This is the job of the .po reader.

Right, the .po reader converts it back to system specific line-ending.

V?clav, apparently it works if you add #13#10 to a resource string. It shows as \n in .po files and you can use it in translations, too. No need for an extra tool for that.

This whole question started from my cleanup work in Lazarus IDE sources for quotation chars '"' which were also passed as Format() params but now they are hardcoded in resource strings. Line-endings are still passed as params. It would be possible to replace them, too, but that is a huge task and I am not planning to do it now.

I must apologize for the extra work for translators caused by my cleanup. There are many fuzzy translations now with wrong number of parameters. Finally please use the PoChecker tool to ensure there are no hidden errors left.
This creates more work in short term but makes things easier in long term. The long param sequences like %s%s%s%s%s are gone now.

Regards.
Juha

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Can someone change the title of the bug-report #26343 to something that is more descriptive and refers to what we are talking about there?

eg.: lazaruside.*.po contains semi converted and/or confusing strings: "%s%s%s"

- --
P?ter G?bor

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJToDD6AAoJEE1Yo2EgEMCokzEIAIQBHvmYv2GjeeNtR0sVVs7X qhjWEIHrjdP+x9/kjaI5Hd0BJdqPbmdnS5JuJ7Hs0i7g970yaqkfsZh2NgCUXz8H qAt7vAGUycr/GT4s6vYAQHGDTzFCPBadDMo530FW/MNEiHE9QvsG/e/K4Z4IvLu1 lw39RBAI+bBNdfjKOv6x3qN7SIHGT2nARaVG8qfMaZF7jfr2EScDdxgl4Egbo8My ev+9gKgamNIoNKuAmtjsuKfYmgNYk3TxMIip+/YAOV8iHnT0kt+VLGVxC5ovb7HP LN1HhVjE9ibqOCGcyjIaBMFVLm645/6QF7+UHkENO8Hk5+KsU+TqTHb1HuMTw7U= =dW3C
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x2010C0A8.asc
Type: application/pgp-keys
Size: 2649 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140617/2895a7fe/attachment.bin> -------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x2010C0A8.asc.sig
Type: application/pgp-signature
Size: 287 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140617/2895a7fe/attachment-0001.bin>

I will explain what has happened so far.

First I noticed the usage of double quote character in resource strings is inconsistent. Some were hard coded inside a string and some were passed as Format parameter %s.
Together with other parameters they often formed long, 5 or 6, parameters in row. Their meaning was not obvious and had to be dug from source code.

I changed some and removed few duplicates, but then I decided to switch all quotation marks to hard coded. They were plenty but still it is only a small fraction of all resource strings in Lazarus project. Often the resource strings are generated with a tool. It used to add parameters for quotes but does't any more. Thus the change was logical, the usage of quotes will be consistent.

G?bor's bug report is about parameters used for newlines. They are not "semi converted". I did not touch them, they have been there always. It seems to be possible to use #13#10 inside the string instead of using parameters. Why is it not done for Lazarus IDE strings, I don't know. Maybe other Lazarus developers could comment on this.

There is a massive amount of those parametrized newlines and the tools are generating more of them. It is not realistic to change them, although I personally would like to see parameters used only for truly varying data.

Regards
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140617/c12c8fc7/attachment.html>

V?clav Val??ek

Dne 17.6.2014 11:24, Juha Manninen napsal(a):

Okay.

This is why I was using gettext from Delphi in my own projects.

Sometimes translators (and maybe developers) need to reorder the appearance of parameters using the parameter ordering feature of Format() function. See:
http://www.freepascal.org/docs-html/rtl/sysutils/format.html Which is very difficult without exactly knowing the meaning of all %s symbols.

Here is an example source string:
msgid="There is already a file%s%s%sin package %s" An ugly translation for Hungarian language:
msgstr="M?r van egy %s%s%s f?jl a(z) %s csomagban"

It would look more friendly and natural for users this way: msgstr="A(z) %3:s csomagban%0:sm?r van egy %1:s f?jl"

Note: in this source string %0:s and %2:s is for new line and may/can be ommited if no need for (one of) them in the translation.

The first translation will look like this:
M?r van egy
unit99.pas
f?jl a(z) valami99 csomagban

The second translation will look more user friendly, like this: A(z) valami99 csomagban
m?r van egy unit99.pas f?jl

(A little explanation: "A(z)" is meaning two possible definite article depending on the first letter of the next word: "az" before vowels and "a" before consonants. I don't know about that gettext supports this kind of language features.)

Today the string mustcontain the same number of %s symbols (including the ones referencing for LineEndings) to avoid getting error messages from POChecker.
Rewriting of (resource)strings (and the related source codes) using hardcoded LineEndings (#13#10 or #10 or #13) will place \n into .po files at the right positions and on re-reading them system specific LineEndings will be placed into the memory.

So POChecker will not shout if a %s (which is for LineEnding) is missing and translation can/will be easier, producing much more user friendly Lazarus... and application created with it.

Finally: I think that if the above changes will be done the result will go beyond the translations, it will result in a better and managable source code for Lazarus.
2014-06-17 15:52 keltez?ssel, Juha Manninen ?rta:

I must say I agree mostly.
Does anybody know why parameters are currently used for newlines? Logically parameters are meant for varying data.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140617/93290feb/attachment.html>

I'm not sure, it it is real reason, but I was forced to use delphi gettext lib becose Lazarus/Freepascal po parser was unable to load \n into translated resourcestring or maybe wasn't able to generate po file with \n... Really not sure..

V?clav Val??ek

Dne 17.6.2014 20:12, Juha Manninen napsal(a):

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

I must say I agree mostly. Does anybody know why parameters are currently used for newlines? Logically parameters are meant for varying data.

In the old days special characters were not converted properly.

I just tested:

'A'#10'BC' is converted to
msgid ""
"A\n"
"BC\n"

Note the new line behind BC. When this is fixed, I can adapt the 'Make resourcestring dialog'.

Also all line breaks (#10, #13, #13#10) are converted to \n and on loading to the system line break. That's ok for all strings passed to the LCL, but all other must be checked manually.

Mattias

2014-06-18 09:44 keltez?ssel, Mattias Gaertner ?rta:

What is about that all systems has its own LineEnding? eg.: a single #10 or a single #13 is not marking EOL on windows, #13 is not marking EOL on Linux, etc.

However EOLs of other systems seems to have no special meaning on each systems, just a whitespace...

\n is automatically converted using the LineEnding variable when the PO-reader parses it. So you are only out of luck if you want a resourcestring that should contain e.g. #13#10 on e.g. a Linux system.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140618/9a5336f3/attachment.html>

I asked about different LineEndigs because of the resourcestrings which are written by developers working on different operating systems. They may put different LineEnding in resourcestrings if they don't use the LineEnding constant, but writing #13#10 or #10 or #13 as it is usual on their system. In this case the compiler on an other system may not accept the hardcoded line ending as it is wished by the developer.

If the string 'Linux#10is great!' will be compiled on Linux it will become 'Linux \n is great!' but when compiling on windows it will not have the \n in it.

If the string is written like this: 'Linux'+LineEnding+' great!' will be compiled on both systems to 'Linux \n is great!'

Using #10 instead of +LineEnding+ is faster so I think a lot of developers will use this to insert new line marker in their strings.

2014-06-18 19:56 keltez?ssel, Sven Barth ?rta:

PO-reader works system specific so \n will be converted to #10 on linux and #13#10 on windows, etc.

But what does PO-writer with #10, #13 and #13#10 in a single resourcestring? Like this: 'How'#10'many'#10'lines'#13#10'here?'

It converts only the system specific LineEnding to \n or it converts all possible (other systems' LineEnding) values to \n?

The second ("all-are-the-same") approach is used by ShowMessage(). The following will have 3 line breaks inside the string on all operating systems:

	ShowMessage('How'#10'many'#13'lines'#13#10'here?');

2014-06-19 07:07 keltez?ssel, P?ter G?bor ?rta:

Yes, it could be problem. I was writing #13#10 under windows, but when I started to rewrite localizations in some of my sources, I'm using

resourceString = 'This is multiline' + sLineBreak + 'resourcestring.'

I think that to type new line after sLineBreak, LineEnding etc. Is very good for code readablity... At least for long texts...

V?clav Val??ek

Dne 19.6.2014 07:07, P?ter G?bor napsal(a):

All three #10, #13, #13#10 are converted by the Lazarus .po generater on all platforms to \n. And this will be converted on loading to LineEnding.

The problem is the original untranslated resourcestring, that contains the #13 or #10. So if no translation is loaded, the line endings may be wrong for the platform.

To be safe: use LineEnding instead of #10,#13.

Mattias

'How\nmany\nlines\nhere?\n'

Note the last \n. That is a bug and needs fixing.

Mattias

Many LCL strings accept all line endings.

Mattias

Mattias, what tool exactly does it wrong?

From the new message: To be safe: use LineEnding instead of #10,#13.

Already a long time ago I changed all #13 parameters to LineEnding in Format() calls.
#13 did not work on Linux, the lines were concatenated in message boxes etc. Apparently the tools still generate #13 as they keep popping up. This should be fixed, too.
I mostly create the resource strings manually so it does not affect me much.

I have translated the IDE texts myself and I agree that the excess parameters make it harder.
They are like useless "noise" when trying to deal with the truly variant parameter data.

Juha

The rst to po converter.

#13 works in message dialogs on all platforms. What message boxes do you mean?

AFAIK the WinAPI and VCL allows to use #13 for line breaks in message dialogs too.

Mattias

Mattias Gaertner wrote

The rst to po converter.

That is part of FPC project.
Even if it was fixed now we cannot start using embedded newlines right away because the previous version of FPC must be supported.

#13 works in message dialogs on all platforms. What message boxes do you mean?

All of the IDE dialogs. Then I was using QT bindings and switching to LineEnding helped. I tested with other widgetsets but I do not remember if the original problem showed up elsewhere.

Juha

No. It's in lcl/translations.pas line 973:

              if MultiLinedValue then begin
                // check that we end on lineending, multilined
                // resource strings from rst usually do not end
                // in lineending, fix here.
                if not (Value[Length(Value)] in [#13,#10]) then
                  Value := Value + LineEnding;
              end;

Then the QT interface behaves differently.
Since all interfaces should do the same here, I put the ConvertLineEndings in LCLBase.

Mattias