issue-#139 Better localization

Merged to the master branch

Re: issue-#139 Better localization

Postby Josef Templ » 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.

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

Re: issue-#139 Better localization

Postby Ivan Denisov » Thu Jan 19, 2017 7:09 pm

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

Re: issue-#139 Better localization

Postby Josef Templ » Fri Jan 20, 2017 9:21 am

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

Re: issue-#139 Better localization

Postby Zinn » Sat Feb 11, 2017 12:39 pm

This issue is still open. Who does work currently on this topic. Are all changes done?
- Helmut
Zinn
 
Posts: 472
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main

Re: issue-#139 Better localization

Postby Ivan Denisov » Sat Feb 11, 2017 7:34 pm

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

Re: issue-#139 Better localization

Postby Josef Templ » Tue Feb 14, 2017 10:25 am

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

- Josef
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#139 Better localization

Postby Ivan Denisov » Tue Feb 14, 2017 3:23 pm

Josef Templ wrote:If nobody else is working on this issue I can offer to finish it.

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

Re: issue-#139 Better localization

Postby Josef Templ » Fri Feb 17, 2017 9:04 am

The changes are in branch issue-#139b.
See the diffs at https://redmine.blackboxframework.org/projects/blackbox/repository/diff?utf8=%E2%9C%93&rev=c893383a84d5c65ce5cc00e89e1930b83f2b4db4&rev_to=40e1932bdb11d6fb9b5fac99941c5ebd90a41bd0.

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

Re: issue-#139 Better localization

Postby Zinn » Sat Feb 18, 2017 2:42 pm

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

Re: issue-#139 Better localization

Postby Ivan Denisov » Sat Feb 18, 2017 3:08 pm

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

PreviousNext

Return to Resolved (Features)

Who is online

Users browsing this forum: No registered users and 1 guest

cron