Hi,

does Free Pascal has a string comparison function that respects locale collations? CompareAnsiString does not seem so...

And while at it, does Free Pascal supports formatting of c-like strings. I mean something like:

writeln(FormatC('\t\t\tThis is a tabbed two-line\n string.'));
That would be great, even neccesary for translation of multiline strings
(*.po files).

Michal

Michal Bukovjan wrote

Hi, does Free Pascal has a string comparison function that respects locale collations? CompareAnsiString does not seem so...

It is not implemented. There is no easy portable way of doing this.

FormatC can easily be implemented and added to SysUtils. If you implement it, I can add it.

Michael.

Nothing a run-time function cannot solve, I would think ? I just don't think that it should be a _language_ feature.

Michael.

Or simply a win32 path.
c:\new windows

We could simply define a tab char, and crlf is already defined afaik.

So one should simply use

'bla'+tab+'bla2';

I have mixed ideas about this. Personally, I don't think it is a good idea, so I'll leave it up to the other core members to decide.

100% against, any form, including adding modes. Totally redundant.

The escaping could be handled by switches, as suggested. That would be perfectly OK, by default escaping would be off, so no breakage.

So how do you these translate (Pascal) expressions with standard (gettext) tools?
How do you generate .po files then?
What about platform independent .lfm files, that contain multiline strings?

Sure, some of this can be written with function, with no extra support from language. Slow, awkward, but can be. At least these could be included SysUtils, then... But I think one cannot use a function for resourcestrings, so again, a dead end.

To my knowledge, all major languages support this, be it Python, Java, C, C++, Perl. Pascal does not support this, but I would not call it a feature, rather a design flaw.

But maybe I am missing something; maybe the issue is more complicated than it seems. You are the wizards :-)

Does anyone know how Borland handles translations?

Michal

I will have a look. If it can deal with expressions, I stand corrected.

I meant the sources, for IDE. But this can be solved the same way as in case of rst2po.

I don't know neither, but I remember that back in time Delphi 5 was supposed to come with some tool for assisting translations. But I never used it, so if someone can shed a light on this...

Michal

On Wed, 11 Sep 2002, Michal Bukovjan wrote:

[cut]

It would. If by any chance there is a '\n' in existing code, for instance in a constant descibing a unix shell command, then this will be broken.

I have mixed ideas about this. Personally, I don't think it is a good idea, so I'll leave it up to the other core members to decide.

If it is implemented, then there should be some switch to turn it off. Something like

{$ESCAPEC ON}       { escape \n etc.}
{$ESCAPEC OFF}      { don't escape \n etc.}
{$ESCAPEC DEFAULT}  { mode dependent. Don't do it in Delphi/TP mode, only in FPC/objfpc mode}

And of course a command-line switch. -Ssomething or so.

Core members, comments ?

Michael.

The rst2po tool takes care of this translation.

What about platform independent .lfm files, that contain multiline strings?

This will fail anyhow, since you will get the string as it was compiled, ie. compiled on linux will result in a #10, on windows in a #13#10.

This is not true.

The solution is very simple; have a look at the existing gettext support. (unit gettext)
You can transform the resourcestrings at program startup as part of the gettext support. This way you can store whatever you want in the resourcestring. At program startup, when localizing, the strings are translated and transformed on the fly...

See also the programmer's manual, the resource string support is covered extensively.

To my knowledge, all major languages support this, be it Python, Java, C, C++, Perl. Pascal does not support this, but I would not call it a feature, rather a design flaw.

No, because normally you don't need this.

It doesn't do any as far as I know.

Michael.

FormatC can easily be implemented and added to SysUtils. If you implement it, I can add it.

ehm... but in C, things like \t are just converted to their ASCII representation by the compiler and get stored as such in the binary. I would suggest to just add a helper function which converts strings with C-like escaped characters to a normal string, instead of writing high-level functions such as FormatC. (something like EscapeC/UnescapeC; the same could be done for other escaping schemes as well)

- Sebastian

Runtime function would be quite slow, I can imagine. But a different idea came to my mind: How about implementing it just for resourcestrings?

- these are constants, so should not be hard to implement (just few regexps, I think)
- this would not break existing string/shortstring/ansistring semantics
- it would enable sane translations
- it could drive users to use resourcestrings when possible, possibly cleaning up code
- at runtime, already translated strings would be present in memory, so no speed penalty.

What do you think?

Michal

To have a platform and language independent tab, newline etc, representation is in fact a very good idea.
It is supported by other languagea as well, like Python or Perl - only Pascal stands out.
Without it (or something similar), it will be virtually impossible to maintain mutliline translations via standard gettext tools.

Michal

Agree fully.

I don't think this is a compiler matter, but a preprocessor matter. In such case it would be better to add general preprocessor support to lazarus or the compiler, and write some standard m4 preprocessing statements for this job.

If we honor requests like this, the sky is the limit and finally code becomes totally unreadable as it is in C. Macroitis is a C disease, and should remain a C disease. So, I don't think this is a good idea.

Michael.