issue-#139 Better localization

Merged to the master branch

issue-#139 Better localization

Postby Ivan Denisov » Fri Dec 23, 2016 8:20 pm

Ivan Denisov
 
Posts: 1698
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Postby Ivan Denisov » Fri Dec 23, 2016 8:46 pm

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
Ivan Denisov
 
Posts: 1698
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Postby Josef Templ » Tue Dec 27, 2016 9:24 am

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Postby Robert » Tue Dec 27, 2016 3:46 pm

Josef Templ wrote: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?
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#139 Better localization

Postby Josef Templ » Tue Dec 27, 2016 4:07 pm

Robert wrote:
Josef Templ wrote: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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Postby Robert » Tue Dec 27, 2016 4:37 pm

Josef Templ wrote: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.
User avatar
Robert
 
Posts: 1023
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#139 Better localization

Postby Josef Templ » Thu Dec 29, 2016 7:14 am

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Postby Ivan Denisov » Sat Jan 07, 2017 9:10 pm

Thanks for all your advices. I am close to publish results, but need some more time.
Ivan Denisov
 
Posts: 1698
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Postby Ivan Denisov » Tue Jan 10, 2017 8:10 pm

Ivan Denisov
 
Posts: 1698
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Postby Zinn » Wed Jan 11, 2017 9:15 am

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
Zinn
 
Posts: 472
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main

Next

Return to Resolved (Features)

Who is online

Users browsing this forum: No registered users and 1 guest

cron