How can I use names with German Umlauts and '?' in the Name Field of TButton components? For instance, I try to set MyButton.Name to "Schlie?enbutton" and get an error message "Komponentenname Schlie?enbutton ist kein g?ltiger Bezeichner".

This happens with Lazarus 1.6 and FPC 3.0.0 under Win 10 (64) and under Raspian on a Pi3.
We have many Delphi Programs with German Umlauts in component names and would like to go to Lazarus with them.
Any hints?

Hans

This is not supported by FPC yet.
You have to rename them.

Mattias

You cannot at this moment.

Michael.

Not supported *yet*?
Shudder.

Martin

Delphi compatibility....
In the unicode RTL, that should be possible.
Together with unicode identifiers, obviously.

Although I am absolutely not in favour of this 'feature'.

Michael.

+1

I am German, but I hope this will never be implemented.

Why? What's so bad with TButton.Name "Stra?eButton" to select "Stra?e" in, for instance, a school program for german kids?

Special wrote

Why? What's so bad with TButton.Name "Stra?eButton" to select "Stra?e" in, for instance, a school program for german kids?

I am german too and I also would not like to have this. Just think about programs written by japanese or chinese programmers using their (unicode) characters in identifiers. Can you read such programs?
Same for the opposite case when german umlauts and such are read by programmers from asia.
What an unnecesseriy increase of complexity.

El 02/04/2016 a las 12:32, Special escribi?:

Why? What's so bad with TButton.Name "Stra?eButton" to select "Stra?e" in, for instance, a school program for german kids?

Messing with ascii codes above 127 is a problem. Look the mess in strings with different char code sets.
Are we going to spread that mess to identifiers?

In html (prior html5), you must say at the beginning of html the document the charset. If you don't, the reader reads crap. Something similar should be done. You would need to make compulsory a command in source code to tell which code set is using. As log as unit and program name could also be "?????", it should be the first command of the source file.

Anyway, that would we another programming language.

Santiago A. wrote

similar should be done. You would need to make compulsory a command in source code to tell which code set is using.

I would hope anybody in this day and age only uses UTF-8 for text files and source code. It was designed to solve the multiple CodePages mess from before.

Anyway, back to the point. I fully agree that anything outside the ASCII range is a bad idea for Identifiers, Unit Names etc. Even if the compiler does support it, using it is still a bad idea.

As a contract programmer I already struggle working on code where identifiers, Class names, methods, code comments etc are written in non-English [I fully agree its their right to do so, as it is not feasible to think everybody can speak or write English]. But adding different character sets to the mix will massively increase that hurdle.

Regards,
- Graeme -

I am chinese.
I also think identifiers should be ascii 7 bit or below only. String values should be UTF-8 as much as possible. It just avoids so many problems.

Dennis

What problems, Denis? We use component names like "Schlie?enButton" since many years with Delphi in training programs for german pupils. And in code for the international community, we don't use it. Regards - Hans

"Special" wrote

What problems, Denis? We use component names like "Schlie?enButton" since

many years with Delphi in training programs for german pupils. And in code for the international community, we don't use it.

*You* might do this, but others might not, they might publish projects on GitHub containing Chinese identifiers.
As funny as the idea of using emojis for identifiers sound as scary it is. So I don't really support this.

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

Special wrote

What problems, Denis? We use component names like "Schlie?enButton" since many years with Delphi in training programs for german pupils. And in code for the international community, we don't use it.

Sometimes it's better to give people less rights. They do less bullshit then ;)

Btw. such english-german identifier combinations make me laugh every time I see them. Why don't you use "Schlie?enSchaltfl?che" if you want to use the German language?

Ondrej

BTW too: Some English words became part of german, like 'Computer' und 'Button'. We don't say "Elektronische Rechenmaschine" any longer, and more and more german book authors say "Button" instead of the strange "Schaltfl?che". Yes, I confess, I used "Schaltfl?che" too in some of my early books three decades ago, but now I don't.
Regards -- Hans

This is an English mailing list, so naturally you will find many thinking the same here.
But many people want to use non English words as identifiers. They need non English letters.

As funny as the idea of using emojis for identifiers sound as scary it is. So I don't really support this.

I share your concerns about non English keywords. For identifiers I see some gain.

Do the linker, assembler, debugger support UTF encoded identifiers? At least on Win, Linux, Mac?

Mattias

"Mattias Gaertner" wrote

> As funny as the idea of using emojis for identifiers sound as scary it

is.

The assembler symbols would need to be escaped anyway to avoid any potential problems. Even more fun with exported/imported symbols...

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

Mattias Gaertner wrote

This is an English mailing list, so naturally you will find many thinking the same here. But many people want to use non English words as identifiers. They need non English letters.

Well, I'm not English and still I do not desire such a feature. I tend to have English names for all
procedures/functions/properties/types as well.
To me it just looks funny to have 2 languages in one file e.g.

procedure HaalConfigurateOp(Bestandsnaam:String);
begin
  If not FileExists(Bestandsnaam) then ...
  with EenDataStructuur do
  begin
    ...
  end;
..
end;

But that's just me.

Bart

Bart wrote

To me it just looks funny to have 2 languages in one file e.g.

:) I agree. Even though I developed Afrikaans application at one point, using English in the source code was much more natural and matched the Object Pascal and RTL English language usage. I like consistency. ;-)

Unfortunately for all non-English speaking people, programming languages and related runtime libraries and other frameworks are very English oriented. I take my hat off for those developers having to battle through that.

Regards,
- Graeme -

Bart wrote

Well, I'm not English and still I do not desire such a feature. I tend to have English names for all procedures/functions/properties/types as well. To me it just looks funny to have 2 languages in one file e.g.

the worst that i've seen is delphi code with russian comments that i have to run through a translator to understand... those translations i generally paste back into the code over the russian text so that others can more easily understand and i won't have to do the translation thing every time i try to dig into the code...

I see a good progress here. The first step was using "Computer" instead of "Elektronische Rechenmaschine", the second step was using "Button" instead of "Schaltfl?che". The next logical step is to teach pupils from the very beginning that the programmer's language is English.

English is part of the compulsory education from very early classes, AFAIK. They definitely can understand the very limited vocabulary needed to write programs. The word "Close" is used in event names, after all. So I really don't see a gain using "Schlie?enButton" instead of "CloseButton".

Ondrej

Bart wrote

To me it just looks funny to have 2 languages in one file e.g.

Just a curiosity from FPC code :)

compiler/tokens.pas:
_LECKKLAMMER (I assume "linke eckige Klammer")
_RECKKLAMMER
_LKLAMMER
_RKLAMMER

rtl/inc/text.inc:
Procedure fpc_Write_Text_Currency(fixkomma,Len : Longint;var t : Text;c
: Currency); iocheck; compilerproc;

Ondrej

Well, that definitely shows that even projects that are now international can have such identifiers from their past... Kinda proves my point ;)

(the best one is _KLAMMERAFFE though ;) )

Regards,
Sven

El 04/04/2016 a las 12:12, Mattias Gaertner escribi?:

This is an English mailing list, so naturally you will find many thinking the same here. But many people want to use non English words as identifiers. They need non English letters.

I'm Spanish, and I don't support non ascii identifiers.

Perhaps for teaching boys would be useful.

MsOffice and libreoffice macro languages even translates functions (ie YEAR()=A?O()). Is that a good idea?. Well for an interpreted language maybe. But I don't think it is a good idea as part of a professional language specification.

Very interesting discussion, I had no opinion before but now I'm totally on the side of no non-ascii identifiers.

But I also understand the desire of the OP who could find use of non-ascii buttons for teaching.

But the answer for these special cases is simple, yes?

Use a label with custom draw/paint and make your own "buttons" using whatever characters you like and use the label's onclick to get where you need to go.

Julius

[...] Use a label with custom draw/paint and make your own "buttons" using whatever characters you like and use the label's onclick to get where you need to go.

No need to. TButton.Caption supports Unicode.

Mattias

Il 02/04/2016 10:14, Special ha scritto:

How can I use names with German Umlauts and '?' in the Name Field of TButton components? For instance, I try to set MyButton.Name to "Schlie?enbutton" and get an error message "Komponentenname Schlie?enbutton ist kein g?ltiger Bezeichner".

Using characters above ascii 127 in a multiplatform environment such as Lazarus and FPC means looking for troubles. Such is not the case for Delphi which is limited to the Windows platform (and manages to make a mess with character encoding even there, BTW).

Any simple text editor can convert your "Schlie?enbutton" to "Schliessenbutton" (and your "kein g?ltiger" into "kein gueltiger", if you like), which are perfectly readable by any German reader and do not cause any subsequent trouble.

As a side note, to play music you need to learn a number of Italian words, because of the prevalence of Italian composers and performers in the past centuries.
To write computer programs you need to manage some basic English for pretty much the same reasons.

Just my 2 cents.

Giuliano

Da capo al fine ;-)

Bart (not Italian)

I used to strictly oppose non-english code as well. A colleague actually managed
to convince me that there are indeed reasons for "localized" identifiers:
in some projects the customers (usually with some industrial background) have pretty
specific wordings or use of the language. If developers now start introducing
their own wording (due to translating back and forth) you complicate the communication and synchronization between business unit and development team.
In such special cases I now "accept" said code style. (Although I still don't
like it ;-))

I think those gains will be limited in scope but the disadvantages are too huge for the general users.
Imagine relaxing this requirement, there will probably be new codes/libraries using non-english identifiers and if they become popular later, a lot of end users might be forced to use these non-english libraries.

e.g. if a hash library A uses a non-english identifier for a library to honour the Thai name of the scholar who invented it. Then an encryption or communication library B uses this library A. If this library B later becomes popular or a standard, all end users using B will need setup their development environment to support non-english identifiers, although only one of the many hash functions in A has non-english identifiers.

I am chinese myself. I cannot even type a Thai identifier, I will then have to copy and paste the identifier. I could also easily confuse one Thai identifier from another one.
Imagine if I write a library with Chinese identifiers, most users won't able to tell apart 2 Chinese identifiers.
e.g.
procedure ?; {means SELL}
begin
end;
procedure ?; {means BUY}
begin
end;

Can use tell them apart easily?

Dennis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160408/1e11dbd3/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: bgjhedgh.png
Type: image/png
Size: 1810 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160408/1e11dbd3/attachment.png>

Dennis wrote

procedure ?; {means SELL} begin end;

The best code obfuscating ever! :-D

Regards,
- Graeme -

Why sometimes come these empty mails ??
?
Is it regular member or some bot?
?
V.
______________________________________________________________

El 02/04/2016 a las 10:14, Special escribi?:

I didn't know Delphi allowed to use above-127 chars for identifiers or component names. Since what version?

The short answer: You can't.

I would say that you needn't, component names are internal, for use in source. Nevertheless, you can use any above-127 chars in captions, that it is what final user sees and must be localized.

Santiago A. wrote

I didn't know Delphi allowed to use above-127 chars for identifiers or component names. Since what version?

I would imagine since Unicode String support was added... So that would be Delphi 2009.

Regards,
- Graeme -

Vojt?ch ?ih?k wrote

Why sometimes come these empty mails from ? Is it regular member or some bot?

I think it's hacked machine...I'll inform that ppl that they are sending spam. btw. I don't see such empty emails. Where do they come ? To your email or to list ?

zeljko

I get them too, they come through the list AFAICS.

Michael.

IMO it is not my local problem, those mails can be found in archive too:?http://lists.lazarus.freepascal.org/pipermail/lazarus/2016-April/thread.html ?
Vojtech
?

Zeljko wrote

I don't see such empty emails. Where do they come ?

I see them too. They come from the list address.

Regards,
- Graeme -

Agreed. For everything related to programming, using Non-English words is a non-sense as you can only lose. How could "Schlie?enButton" make anything better, when you can't invoke "Fenster.Schlie?en" anyway?

The only case when national identifiers make sense is when they come from a business domain. Translation of e.g. financial business terms is not exactly something a programmer should do, so either the customer supplies English terms or I leave them as they are.

Except for removing diacritics. This is fortunately easy for the languages I use. I wonder what I'd do if I used a language not based on a Latin alphabet. Then I might end up with a ?Button.

Regards, Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/b2a6aca8/attachment-0001.html>

2016-04-08 14:13 GMT+02:00 Vojt?ch ?ih?k :

I set the moderation bit on , so those mail won't
reach the list antmore.

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