Bundle strings in dwsStrings

[Christian-W. Budde]

Currently most of the strings are bundled in the unit dwsStrings. However, not all are bundled there so far. Some strings can still be found all over the source code.

This is not bad or problematic, but it would be nice to have it all in one place.

The background for this request is that I want to evaluate how difficult it is to create a localised Pascal dialect for primary schools as often one of the major difficulties at that age is the language barrier.

For example, the dwsCompiler contains strings like 'array of const'.

[Christian-W. Budde]

Currently most of the strings are bundled in the unit dwsStrings. However, not all are bundled there so far. Some strings can still be found all over the source code.

This is not bad or problematic, but it would be nice to have it all in one place.

The background for this request is that I want to evaluate how difficult it is to create a localised Pascal dialect for primary schools as often one of the major difficulties at that age is the language barrier.

[Anders Melander]

Why not use resourcestrings? Then it doesn’t matter where the strings are defined - and they’ll be localizable.

[Christian-W. Budde]

I guess normal strings are faster. However, currently several strings are defined inline and not as const. This makes a basic translation difficult.

For my needs I’m looking forward for just something like a proof of concept, which I can hack somehow for now. Next I need to evaluate if a localized Pascal language would really work or whether it is still better to start with a visual language.

For the beginning a visual laguage can be useful, but as soon as the kids want to create more complex programs, the visual programming language will get very big.

[Anders Melander]

Do you mean the Pascal keywords and reserved words? I thought you meant the compiler and RTL messages.

[Christian-W. Budde]

The pascal keywords and reserved words are already available as constants, but occassionally the constants are not used but inline strings.

But I didn’t want to limit it to this as also the internal RTL and functions should be based on strings. And of course the compiler messages.

For the latter it makes some sense to have them available as resourcestring as they are probably most likely to be changed.

For my proof-of-concept of a fully localised language (keywords, type names, RTL and compiler message) I have created a custom fork. In combination with my Pascal Primer project, I’d like to write a fully localized text based tool that can even be used in primary schools.

This said, I have no idea where to get the time/money from, but it’s my sublime wish to have something available to make the learning curve less steep.

[Eric Grange]

The use of “const” in dwsStrings is essentially to state there is no effort made to maintain or provide “official” translations at the moment (as these can be quite time consuming even just to administer), but they are still consolidated to facilitate it, should localization be supported in the future or in a fork.

There is a notable performance penalty associated to resourcestring because of their dynamic allocation (with an implicit tr..finally), but in most critical cases, the compiler messages have already been moved to local procedures so the impact should be moderate (to segregate them from the normal codepath, whenever the message involved other strings with implicit try..finally).

Localizing keywords and reserved words would be quite different however, at the moment the strings/names associated to token types are derived from their enum name, or from an array of token strings. The two are still coexisting because of long forgotten legacy reason… and lack of incentive. This part of the tokenizer could probably use a consolidation, but I am not sure if the test coverage is sufficient to handle all the corner cases.

Special methods/function names are yet another set of creatures, with some belonging to language extensions. The performance implications of resourcestring could be noteworthy there, so some intermediate storage would be preferable.

As to the goal of translating the language, being French, this is something I had to suffer through, and see others some suffer through, we even have a Delphi competitor here, WinDev, whose language keywords are localized (https://www.pcsoft.fr/wlangage.htm).
I am not convinced this actually provides an advantage, while it can cause a lot of confusion (I saw WinDev students trying sentences and wondering why they gave errors f.i.), I tend to think using keywords in a foreign language is a bit of and advantage, as they then gain a primarily technical meaning with little to no baggage.