Fixing listport output and changing it to a localized BApplication

[Karvjorm]

I noticed that the output of the listport application in src/bin directory does not look so good. So I fixed the output and changed listport.c file to ListPort.cpp file.

But I was not able to do it in src/bin directory. Too many moving parts there just now. So I created a subdirectory src/bin/listport, deleted listport application and listport.o file from generated/objects/haiku/x86/release/bin/. I also commented out listport.c in Jamfile and created a reference to listport subdirectory.

Then I created a new Jamfile to src/bin/listport/ and a new ListPort.cpp file with the localized texts. Now ListPort application will be generated to the listport subdirectory. I suppose, that this ListPort application can be copied to Haiku image and the old listport application should be replaced by the logical link to this new application. But maybe somebody else could do it, because it is too difficult for me.

The only problem is here that path below is too short, only 63 characters: TEAM 1978 (../../../generated/objects/haiku/x86/release/bin/listport/ListP):

[Karvjorm]

Oops, the following comment is not quite correct: "A table header, try to keep the start of single words in the same column."

It should be the end of ...

I will fix it with the other changes later on.

[Karvjorm]

4th ListPortLocalization update including listport.rdef (no idea if resource app_flags are correct)

[axeld]

I'm against applying this patch for the following reasons:

• listport is a very simple command, there is no reason to move it into its own subdirectory
• it's called "listport", not ListPort, so the source file should match
• while I heavily dislike having localized command line applications, I guess others do think otherwise. Still, if possible, I would like to have the command line applications in English, while the rest of the system follows the configured language by default. Not sure, if this is possible already.
• You said "does not look so good": what exactly do you mean, and what exactly did you change?
• Localization changes should be separated from other changes.

[Karvjorm]

Replying to axeld:

I'm against applying this patch for the following reasons:

• listport is a very simple command, there is no reason to move it into its own subdirectory

There are also some other commands with subdirectories, as ideinfo, listdev and playsound.

One advantage with a subdirectory is that you can include also a resource file with app_flags. Before defining application as a B_BACKGROUND_APP (or whatever it was) the new BApplication application popped up in the deskbar once during each run and then disappeared immediately.

• it's called "listport", not ListPort, so the source file should match

That's right, but you can easily fix this by changing "Application listport" and "DoCatalogs listport" to Jamfile. I used this form to be sure that the applications do not be mixed during he "evaluation period".

• while I heavily dislike having localized command line applications, I guess others do think otherwise. Still, if possible, I would like to have the command line applications in English, while the rest of the system follows the configured language by default. Not sure, if this is possible already.

Command line applications are localized in Linux and I like it. You can easily change locale settings to English, if you want to use English command line commands.

• You said "does not look so good": what exactly do you mean, and what exactly did you change?

Here is an example of the old output

TEAM  101 (/boot/system/servers/media_server):
   ID                         name  capacity  queued
----------------------------------------------------
98370                   tmp_rport0         1       0
98371                   tmp_rport1         1       0
98372                   tmp_rport2         1       0
102469                AppLooperPort       200       0
102473                 a<app_server       100       0
102474  a<101:x-vnd.Be.media-server        50       0
114767          __media_server_port        64       0
176236                 AddOnMonitor       200       0
245885               _BMediaRoster_       200       0
245886             media reply port         1       0

and here is output after my fixes:

TEAM   101 (/boot/system/servers/media_server):
        ID                           name  capacity  queued
-----------------------------------------------------------
     98370                     tmp_rport0         1       0
     98371                     tmp_rport1         1       0
     98372                     tmp_rport2         1       0
    102469                  AppLooperPort       200       0
    102473                   a<app_server       100       0
    102474    a<101:x-vnd.Be.media-server        50       0
    114767            __media_server_port        64       0
    176236                   AddOnMonitor       200       0
    245885                 _BMediaRoster_       200       0
    245886               media reply port         1       0

• Localization changes should be separated from other changes.

Yes, this this is right, but included them both here in new application. I could do a fix patch for the listport.c file also. I'll try to include it here as a separate patch.

[axeld]

First of all, thanks for your thorough reply!

Replying to Karvjorm:

Replying to axeld:

I'm against applying this patch for the following reasons:

• listport is a very simple command, there is no reason to move it into its own subdirectory

There are also some other commands with subdirectories, as ideinfo, listdev and playsound.

Usually because they need some special private headers. In general, though, localization is not a good reason to them into a separate directory, because then all command line tools would need to be in one. Instead, we should develop a way to simplify mass localization of the command line tools in the "bin" directory using some additional Jam magic. Of course, this should be done as the first step to localize the command line apps.

Aren't there any GUI apps to be localized first? ;-)

Anyway, your persistence and motivation to work on localization is very much appreciated, please don't get me wrong.

One advantage with a subdirectory is that you can include also a resource file with app_flags. Before defining application as a B_BACKGROUND_APP (or whatever it was) the new BApplication application popped up in the deskbar once during each run and then disappeared immediately.

As you already write, this issue has been fixed long ago :-)

• it's called "listport", not ListPort, so the source file should match

That's right, but you can easily fix this by changing "Application listport" and "DoCatalogs listport" to Jamfile. I used this form to be sure that the applications do not be mixed during he "evaluation period".

Not sure what you mean by that.

Command line applications are localized in Linux and I like it. You can easily change locale settings to English, if you want to use English command line commands.

Same for the other direction :-) Having english command line tools by default has the added advantage that when you share stuff with others (be it in a bug tracker, or a forum) everything will use the same language. It also helps with writing scripts.

Here is an example of the old output

[...]

Thanks! Having a separate patch for the output improvement would be nice, as this patch could be applied without further ado.

[Karvjorm]

Replying to axeld:

First of all, thanks for your thorough reply!

Replying to Karvjorm:

Replying to axeld:

I'm against applying this patch for the following reasons:

• listport is a very simple command, there is no reason to move it into its own subdirectory

There are also some other commands with subdirectories, as ideinfo, listdev and playsound.

Usually because they need some special private headers. In general, though, localization is not a good reason to them into a separate directory, because then all command line tools would need to be in one. Instead, we should develop a way to simplify mass localization of the command line tools in the "bin" directory using some additional Jam magic. Of course, this should be done as the first step to localize the command line apps.

Aren't there any GUI apps to be localized first? ;-)

Yes, but because HTA is offline, I'm not absolute sure which GUIs are already localized. For example, I made a part of filepanel localization (in src/bin) and someone else had done other part of filepanel localization. So I have waited for the updates for the development environment.

Anyway, your persistence and motivation to work on localization is very much appreciated, please don't get me wrong.

One advantage with a subdirectory is that you can include also a resource file with app_flags. Before defining application as a B_BACKGROUND_APP (or whatever it was) the new BApplication application popped up in the deskbar once during each run and then disappeared immediately.

As you already write, this issue has been fixed long ago :-)

• it's called "listport", not ListPort, so the source file should match

That's right, but you can easily fix this by changing "Application listport" and "DoCatalogs listport" to Jamfile. I used this form to be sure that the applications do not be mixed during the "evaluation period".

Not sure what you mean by that.

At present you can find in my src/bin/lisport/Jamfile file lines like "Application ListPort" and "DoCatalogs ListPort". But if I (or you) change it to "Application listport", we have listport executable generated (not ListPort executable) in generated/objects/.. etc.

Command line applications are localized in Linux and I like it. You can easily change locale settings to English, if you want to use English command line commands.

Same for the other direction :-) Having english command line tools by default has the added advantage that when you share stuff with others (be it in a bug tracker, or a forum) everything will use the same language. It also helps with writing scripts.

It is not so big problem in Linux. For example, if you as a developer received an error message with the localized text like "tiedosto rikkinäinen", you can always check it with the google:

"tiedosto rikkinäinen site:translationproject.org"

And the only link is

​http://translationproject.org/PO-files/fi/gprof-2.20.1.fi.po

There you can find the text:

#: gmon_io.c:370
#, c-format
msgid "%s: %s: found bad tag %d (file corrupted?)\n"
msgstr "%s: %s: virheellinen tunniste %d löytyi (tiedosto rikkinäinen?)\n"

Here you will see that the localized text means "file corrupted" and it can be found in gmon_io.c file on the line 370. The problem with the Haiku localization is that you have not selected .po file form for catkeys and origin of localized texts is not so easy to trace.

If we will localize also command line tools, so we are making use of Haiku easier for millions of future users, but a bit difficult for some hundred developers. Most users probably never use the command line tools, but I know that if some accidentally do so, they can became very confused and angry: "What is that application doing? What does it do with my computer?" That is because they do not understand English output.

[Karvjorm]

an output fix for src/bin/listport.c

[pulkomandy]

Hello, Now there is no conflict for multiple DoCatalogs rules in the same folder, see what I did for dstcheck in hrev38617 , and do the same for this one.

[Karvjorm]

Replying to pulkomandy:

Hello, Now there is no conflict for multiple DoCatalogs rules in the same folder, see what I did for dstcheck in hrev38617 , and do the same for this one.

Sorry, the link to hrev38617 above does not work in my browser. But in some email I saw that you had replaced en.catkeys with dstcheck.catkeys. What about those de.catkeys, fi.catkeys or fr.catkeys that will be generated in hta? There will be several de.catkeys in bin folder, for example.

[anevilyak]

That should've been hrev37617 .

[diver]

Can we close this one?

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed