issue-#139 Better localization

[Ivan Denisov]

Better localization of compiler messages and error marks.

http://redmine.blackboxframework.org/issues/139

Changes:
http://redmine.blackboxframework.org/pr ... 38f8d9c26c

Error mark view also looks better now
http://blackboxframework.org/unstable/i ... a1.752.zip

[Ivan Denisov]

For testing this issue you can install Russian localization pack:
http://comp.molpit.org/blackbox/russian.txt

install, switch to Russian and see that all error marks and messages will be in Russian

[Josef Templ]

The Dev/Rsrc/Strings.odc file should be extended for the error messages.
Otherwise it is impossible for anybody working on a translation to see which keys are required.
A possible name pattern for the keys would be "Kernel.err.xxx".
Thereby anybody working on a translation sees immediately what the keys are used for
and it avoids potential name conflicts with other keys.
e.g.
Kernel.err.129 invalid WITH
Kernel.err.>=20 precondition violated <<< note that this is without formatting with leading spaces and ( )

"illegal memory read", "ad", etc. are still not localizable.
"ad", BTW, should be changed to "adr" because "ad" is an unusual and at least for me a very
confusing abbreviation for "address" (it looks like the misspelled name of a register).

Adding the "#Dev:" prefix inside LogWStr makes it hard to see the keys in use.
I would suggest to specify the full key as the parameter even if it adds a few bytes.
It makes it easier to see that there is a mapping involved. It also makes it possible to
search for a specific key in all the sources.


DevMarkers.Load
Should use the test "IF (Dialog.language # "") & (Dialog.language # "en") THEN".
Should add an "ELSE view := NIL" in order to avoid uninitialized variable "view".
Also, the test "IF langLoc # NIL THEN" should be changed to "IF langLoc.res = 0 THEN".

The error markers look much better now.

- Josef

[Robert]

Should add an "ELSE view := NIL" in order to avoid uninitialized variable "view".

Surely this is unnecessary as View will be initialised to NIL when the procedure is called?

[Josef Templ]

Should add an "ELSE view := NIL" in order to avoid uninitialized variable "view".

Surely this is unnecessary as View will be initialised to NIL when the procedure is called?

OK, this is debatable.
The problem is that the analyzer still marks uninitialized pointers
at least in simple situations (the analyzer is not very smart about data flow).
(There is also a compiler option that switches off pointer initialization.)
In most cases I have seen there is explicit initialization of local pointer variables,
so I would stick with that unless it is highly time critical.
It also makes it easier to read the sources.

- Josef

[Robert]

OK, this is debatable.

The language report explicitly says it is unnecessary (so please don't choose compiler options that mislead people who assume that the compiler will obey the report).

It becomes mainly a matter of taste (since the wasted time and space are usually small). Personally it annoys me as much as seeing:

Code: Select all

VAR flg : BOOLEAN;
IF flag = TRUE THEN ...

It not wrong, but it does not look right to me.

[Josef Templ]

As far as I know local variables in general are not initialized in CP.
This is in line with the tradition of Pascal-style languages.
Even in Java and C# local variables are not initialized automatically.

The only exception are pointers (and procedure variables) in CP.
My conclusion therefore is that this should better be documented in the
platform specific part of the docu, not in the language spec.

The "IF flag = TRUE" example is a different topic where we all agree.

- Josef

[Ivan Denisov]

Thanks for all your advices. I am close to publish results, but need some more time.

[Ivan Denisov]

The new version:
http://blackboxframework.org/unstable/i ... a1.758.zip

[Zinn]

Dear Ivan,
you have done a lot of work, but the result is not as easy readable as the original one.

For example when we read the line
ELSIF Kernel.err = 130 THEN LogWStr("Kernel.err.130")
then we don't know what is Kernel.err.130.
In the original module we read
ELSIF Kernel.err = 130 THEN out.WriteString("invalid CASE")
and we know immediently which error it is.

Why you don't change this line to
ELSIF Kernel.err = 130 THEN LogWStr("invalid CASE")
or
ELSIF Kernel.err = 130 THEN out.WriteString("#System:invalid CASE")
?

And I have another question: What is the reason to change the f.DrawLine in DevMarkers from
f.DrawLine(point, 0, w - 2 * point, h, 0, color);
f.DrawLine(w - 2 * point, 0, point, h, 0, color)
to
f.DrawLine(point, 0, w - f.dot, h, 0, color);
f.DrawLine(0, h + f.dot, w, - 2 * f.dot, 0, color)
?

- Helmut