Error Exception only english

[EgonHugeist]

sfxcc, Pitfiend,

declared all Messages as Varable in ZMessages.Pas. They will be load on intiialization the Unit. And you can override them if you want. Just be carefull with formated Messages!

Rev.2026 /testing-7.1 (SVN)

[Pitfiend]

Hi my dear friends, I was trying to build a localization solution. I found it's a bit of pain in the butt. The other thing I try, was to make all languages available on run time to be able to switch upon a conditional property, unfortunately this ends in a big footprint. I also try to build dynamic libraries or language files, founding that you need to deploy them with your app (something I don't like or want as many of you). I think that the original solution using defines is still unbeatable. In the other hand, having the messages as variables instead of string resources is very handy, but we already point that we don't like this behavior because of the external dependencies. It's my opinion that the original solution must be kept and enforced with clear documentacion.

[EgonHugeist]

Pitfiend,

the current constants are resourcestrings. This i haven't changed. I only load them on intialization into the Varables. So you can manipulate the recourcestrings too or overwrite the variables.

Anyway thank's for trying to find a better solution. If you want then have a look to ZMessages.pas on \testing-7.1 (SVN). For the current branches we've a behavior freeze so i couldn't commit the changes too.

[mdaems]

Any idea about the memory footprint?
Wondering if we can't even make it easier by providing the list of messages as a stringlist (one for every language we support). And then have a procedure that reads a stringlist to fill the message variables. That way our users can just overwrite all values by loading their own (eventually partial) version of the stringlist using a simple function instead of having to override all values one by one.
Is it easy to write a stringlist in your code in a way that can be read eaqually easy by FPC as by Delphi?

Mark

[EgonHugeist]

Any idea about the memory footprint?

Nope. Memory is allocated twice i think. One for the resourcestring-constants and one for the variables.

providing the list of messages as a stringlist

How do you wanna make this list persistent? To be clear we are talking about messages/error-strings which are used from core-Layer up to component+component-design layer. Proposals?

All i can imagine are two solutions:
First:
A new Component which goes the way you propose. This contains all available variables as list-strings and these can be assigned after initialize this component to these variable. But IMHO this leads to pain again since we can't change the order of Component-Creation.

Second:
Again a component which can edit the resourcestrings. But where? actually we've no res file bound except the automatically generated one of the packages. We can create one and check best practice. Ok that would be the nicest way. Remaining are problems with strings we use for Formated Strings. And how to handle diffent languages there too? New property editor + some tabcontrols + utf8 encoded unit to handle all languages we can support?

All i did was currently accept the proposal of Sergio(SFXCC) which was easy to implement. All other solutions need a lot of more care and workout. Or do i think to complicatad in this domain?

[Pitfiend]

one of my approaches was to use variables and a kind of ini files for each languages with a loader. but you must provide some ini files with your app, if none is provide it defaults to english strings. it even works with resource strings, but it complicates the loader. i think that we can drop the resources strings in favor of variables in a global unit. this has the benefit of portability, not sure if the resource strings work the same in windows, linux or osx/ios.

[EgonHugeist]

Pitfiend,

I'm also not sure if it works with ressource Strings. Two problem we have: keep only one language and do not break the portabillity with Delphi vs. FPC. Thanks for your approach. If somebody else has a better suggestion or patch: i will apply it. (;

[Pitfiend]

I'm aware about the portability issues, that's why I enforce the variable thing with a loader. How the language file is constructed is not the matter, I suggested ini files just because they are standard (I think), but can be any kind of text files (one string per line).

[mdaems]

A late reaction. But the information may still be usefull for people who use resource string technology to translate their application.

In SVN revision 2062 (testing7.1) I moved the error string loading to a public procedure ZMessages.loadmessages(). That way it's possible to reload the messages after updating the ressource strings.

Mark