issue-#139 Better localization
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
issue-#139 Better localization
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
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
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#139 Better localization
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
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
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#139 Better localization
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
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
Re: issue-#139 Better localization
Surely this is unnecessary as View will be initialised to NIL when the procedure is called?Josef Templ wrote:Should add an "ELSE view := NIL" in order to avoid uninitialized variable "view".
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#139 Better localization
OK, this is debatable.Robert wrote:Surely this is unnecessary as View will be initialised to NIL when the procedure is called?Josef Templ wrote:Should add an "ELSE view := NIL" in order to avoid uninitialized variable "view".
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
Re: issue-#139 Better localization
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).Josef Templ wrote:OK, this is debatable.
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 ...
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#139 Better localization
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
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
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#139 Better localization
Thanks for all your advices. I am close to publish results, but need some more time.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#139 Better localization
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
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