Socket friendly directories

[digable1]

This provides a way to get the friendly directory name: For example, directory socket anygenre2.jamulus.io:22224 has a friendly name of "Any Genre 2" on the Jamulus client - and previously no current way to get to that friendly name in the API.

CHANGELOG: Adds API call jamulusclient/getSocketAndFriendlyDirectories

Context: Fixes an issue? No

Does this change need documentation? What needs to be documented and how? JSON-RPC doc

Status of this Pull Request

??

What is missing until this pull request can be merged?

??

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[mcfnord]

I only recently learned that friendly names are translated. So is this result translated? English is requested for our github discussions, but why would an API want an English-only friendly name?

[ann0see]

I think we consistently don't translate in JSON-RPC?

[mcfnord]

I think we consistently don't translate in JSON-RPC?

Are there other examples where we return a string that gets localized in the GUI? It's not the right way to store the directory, compared to the canonical machine-readable name. And it's not the right string to show users, who don't necessarily know that string. I would use the canonical, machine-readable name and then look it up in my own copy of your localization table to get the translated string. When would an English-only string be more reliable and useful than that?

[digable1]

This PR is not about translation. It's about getting the 'friendly name' in any context (and in this environment, we have settled on English).

@ann0see is right: This is API work, not for human display in a UI/UX setting. Therefore, translations should be confined to the visual side of the product. The user of the API can handle their own translation as needed.

That being said: If we want an optional argument to this method being the locale code (en_us, fr_CA, etc), that would present a consistent binding of how the Jamulus client renders the friendly directory name, so the actual friendly name remains consistent everywhere for all interactions, GUI and API.

[digable1]

And: This does not take into account translating custom directory names, of course.

[pljones]

@digable1 I've updated your PR (third one). Could you follow the instructions in the comments more carefully, please.

[pljones]

Please use git rebase not git merge from jamulussoftware/jamulus main -- it makes the history a lot clearer.

[digable1]

@pljones - Well I was taking the easy way out: When I see Jamulus main updated, I press the "Sync fork" button in Github - for all the branches that contain the PRs. However, Github uses merge and not rebase when I do that (https://github.com/orgs/community/discussions/48935#discussioncomment-14261151).

There are instructions on how to rebase via the command line in that post - manually via the CLI. There's also https://kb.mautic.org/article/how-to-rebase-branch-and-sync-forked-repository-with-upstream-using-git.html

I haven't actually modified my PR code. One reason I do this 'merge' is to keep my PRs up to date and reduce any conflicts when it's brought in to Jamulus main branch. However, the primary reason to merge-now-rebase is to test the latest code with my changes built in on my fork to see if it things still works.