Re: issue-#139 Better localization
Posted: Wed Jan 11, 2017 1:49 pm
The changes in DevMarker are for improved rendering of the X
with precise 45 degrees, i.e. without irregular steps.
@readability:
Using the error numbers as the key is basically fine for me.
It avoids any possible key conflict and is very systematic as can be
seen from the nice "error table" that results in the Strings file.
But I also see Helmut's argument and may be here is a solution that fits it all.
I was thinking about the reason why the trap window was not
localizable in BB 1.6. It can be an oversight, a simplification, or the
idea that error reporting should work under all circumstances, i.e.
without the dependency on possibly missing resource strings.
The last point leads me to the following suggestion that also improves readability.
It simply adds a default for the case where the mapping is not available.
This makes some additional changes:
1. it renames LogWStr because the name is misleading; it does not write to the log but to out
2. it removes the export flag because an export is not required
Some more remarks:
StdDebug.Trap: 143, 144, 200 need to be changed as well. Please check every error number carefully.
"TRAP" is still not localizable
System/Rsrc/Strings.odc:
the following entries mix translation and formatting. I think Strings.odc should only contain the translationIt should be for example:
note the removed ( ) and the removed leading spaces.
The following entries also mix translation and formatting in an even stranger way.
I think it would be best to make a separate entry for "adr".
- Josef
with precise 45 degrees, i.e. without irregular steps.
@readability:
Using the error numbers as the key is basically fine for me.
It avoids any possible key conflict and is very systematic as can be
seen from the nice "error table" that results in the Strings file.
But I also see Helmut's argument and may be here is a solution that fits it all.
I was thinking about the reason why the trap window was not
localizable in BB 1.6. It can be an oversight, a simplification, or the
idea that error reporting should work under all circumstances, i.e.
without the dependency on possibly missing resource strings.
The last point leads me to the following suggestion that also improves readability.
It simply adds a default for the case where the mapping is not available.
Code: Select all
PROCEDURE OutStr (IN key, default: ARRAY OF CHAR);
VAR str: ARRAY 128 OF CHAR;
BEGIN
Dialog.MapString("#System:" + key, str);
IF str = key THEN str := default$ END;
out.WriteString(str)
END OutStr;
PROCEDURE Trap;
BEGIN
...
IF Kernel.err = 129 THEN OutStr("Kernel.err.129", "invalid WITH")
...
1. it renames LogWStr because the name is misleading; it does not write to the log but to out
2. it removes the export flag because an export is not required
Some more remarks:
StdDebug.Trap: 143, 144, 200 need to be changed as well. Please check every error number carefully.
"TRAP" is still not localizable
System/Rsrc/Strings.odc:
the following entries mix translation and formatting. I think Strings.odc should only contain the translation
Code: Select all
Kernel.err.125 (call of obsolete procedure)
Kernel.err.126 (not yet implemented)
Kernel.err.>=100 (invariant violated)
Kernel.err.>=60 (postcondition violated)
Kernel.err.>=20 (precondition violated)
Code: Select all
Kernel.err.125 call of obsolete procedureThe following entries also mix translation and formatting in an even stranger way.
Code: Select all
Kernel.err.203b illegal memory read (adr =
Kernel.err.204b illegal memory write (adr =
Kernel.err.205b illegal execution (adr =
Code: Select all
Kernel.err.203b illegal memory read
...
Kernel.err.adr = adr