issue-#139 Better localization

Merged to the master branch
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Post by Josef Templ »

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.

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")
		...
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 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)

It should be for example:

Code: Select all

Kernel.err.125	call of obsolete procedure
note the removed ( ) and the removed leading spaces.

The 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 = 
I think it would be best to make a separate entry for "adr".

Code: Select all

Kernel.err.203b	illegal memory read
...
Kernel.err.adr = adr
- Josef
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Post by Ivan Denisov »

Josef, I was thinking several days about you proposal. I do not like this.
This is some kind of over-engineering. It is better to have simple mapping as it was my first suggestion.

However I agree that we should add this phrases to the Strings file to provide some help for possible translators.
The same phrases used in DevDebug and StdDebug, so they stored in System/Rsrc/Strings.

http://blackboxframework.org/unstable/i ... a1.759.zip

I found that DevCPM also has untranslated messages in FPrintErr procedure... I have to work on this.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Post by Josef Templ »

This is also OK for me.

Please note: there are still some strings not translated.
Searching for "out.WriteString" in Trap yields:
StdDebug:
"illegal memory read", "illegal memory write", "(adr = "
DevDebug:
"(adr = ",


@DevCPM
You probably mean DevCPT.
Yes it has some untranslated strings as well.
In addition there is one place in DevCPP.CheckUnimpl.
Again the formatting and the translation should be separated.
The strings will probably go into Dev/Rsrc/Strings.

In the case of DevCPP.CheckUnimpl it seems to me that a parameterized
mapping would be appropriate.

- Josef
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#139 Better localization

Post by Zinn »

This issue is still open. Who does work currently on this topic. Are all changes done?
- Helmut
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Post by Ivan Denisov »

Zinn wrote:This issue is still open. Who does work currently on this topic. Are all changes done?
- Helmut
Hi Helmut, I took some pause. I had no time these weeks to finish this issue. If somebody wants to finish this work that's OK for me.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Post by Josef Templ »

If nobody else is working on this issue I can offer to finish it.

- Josef
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Post by Ivan Denisov »

Josef Templ wrote:If nobody else is working on this issue I can offer to finish it.
I agree.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Post by Josef Templ »

The changes are in branch issue-#139b.
See the diffs at https://redmine.blackboxframework.org/p ... bd90a41bd0.

Note: I had to create a new branch because pushing to branch issue-#139 was not possible
for unknown reasons. It may be that there was a subtle situation with DevCPP,
which missed the change of issue-#134. But normally this would only show up as
a merge conflict when merging to master.

Adding the localization support for the compiler log messages required a new
procedure DevCPM.LogWPar, which happend to provide an opportunity for removing
Utf8-conversion from OPP and OPT and to centralize it in DevCPM.
Much simpler structure now.

Just by accident I discovered that DevDebug/StdDebug already had a procedure
named OutString that was almost identical to OutStr. So I merged them.
This has also the advantage that the qualified key is visible in the source code directly
and follows the usual programming pattern.

Otherwise the changes are in line with Ivan's version.

- Josef
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#139 Better localization

Post by Zinn »

In the download directory of #139b there is the exe & zip file of version 767 missing. So I can't test the changes here.
Helmut
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#139 Better localization

Post by Ivan Denisov »

Zinn wrote:In the download directory of #139b there is the exe & zip file of version 767 missing. So I can't test the changes here.
Helmut
I think that it can be compared with last master
http://blackboxframework.org/unstable/m ... a1.760.zip
Post Reply