Country list sort order

[MrGettingRatherFrustrated]

I have an open bug with WHMCS but no response so far.

The country list order is based on the physical order in the dist.countries.json  rather than being ordered by the display name - however language overrides don't alter the order and once translated it looks a mess as it doesn't appear to be in any logical order (for the customer) - does anyone know how I can force the display sort order to be alphabetical without having to physically over write and reorder the json file?

Thanks

[brian!]

16 minutes ago, MrGettingRatherFrustrated said:

I have an open bug with WHMCS but no response so far.

good luck with that, they wouldn't consider this to be a bug... and even if they did...

18 minutes ago, MrGettingRatherFrustrated said:

The country list order is based on the physical order in the dist.countries.json  rather than being ordered by the display name - however language overrides don't alter the order

are you trying to use Language overrides to change the content of the list, and not the documented method ?

https://docs.whmcs.com/Customising_Countries_and_Calling_Codes

19 minutes ago, MrGettingRatherFrustrated said:

and once translated it looks a mess as it doesn't appear to be in any logical order (for the customer) - does anyone know how I can force the display sort order to be alphabetical without having to physically over write and reorder the json file?

you could get the array in a hook, asort it and return the sorted array back to the template....

though you might need to do that separately for each occurrence of the list as the different templates will almost certainly use different variable names for the same array - from memory, the list will be shown to the client at checkout (multiple different arrays), upon registration, modifying client details, contacts... you can do it with one clientareapage hook triggering on different templates and pulling/returning the relevant array for that template.

[MrGettingRatherFrustrated]

No, I am using a country.json as documented.

The whole json mechanism for states, countries etc is flawed, consider the not so uncommon scenario of wanting to support multiple language - concurrently, like using the advertised feature of the 25 or 26 supported languages (supposedly)

 All these elements are in English only, overridable to an alternative language via states, domains. countries etc 
The fact all of this defaults to the site operators locale rather than the language chosen by the visitor/customer is all part of that same architectural flaw - you could say its a failure to design at all for this supposed advertised product capability...

I have a very dirty and nasty mechanism which allows me to actually use a different file for these elements based on the language choosen - it's sounding like overwriting and reordering the dist.countries.json is going to be the easiest although most tedious option and I'll have to reinstate the modified files post upgrades 

Edited February 19, 2021 by MrGettingRatherFrustrated

[brian!]

19 hours ago, MrGettingRatherFrustrated said:

The whole json mechanism for states, countries etc is flawed, consider the not so uncommon scenario of wanting to support multiple language - concurrently, like using the advertised feature of the 25 or 26 supported languages (supposedly)

well WHMCS multilingual support throughout the product is terrible - always has been... features will either not be completed thoroughly to their logical end, or not even provided with translatable options.

19 hours ago, MrGettingRatherFrustrated said:

All these elements are in English only, overridable to an alternative language via states, domains. countries etc 

well I think States are s-l-o-w-l-y being moved to use a system similar to dist.countries.json - at best that's months away, but I suspect far far longer.

with regards to countries, WHMCS think this translatable feature already exists...

https://requests.whmcs.com/topic/the-ability-to-translate-country-names

for what the OP and you want to do, you can't do it from settings - contrary to what is suggested in the request reply.

20 hours ago, MrGettingRatherFrustrated said:

The fact all of this defaults to the site operators locale rather than the language chosen by the visitor/customer is all part of that same architectural flaw - you could say its a failure to design at all for this supposed advertised product capability...

I would say it's also caused by the design team being Anglo-US with non-English features/testing being an afterthought.. if a feature works in English, great; if a feature looks crap or just doesn't work in another language, then we'll get around to fixing it at some future point (or not).

this definitely wouldn't be considered a bug - it's a FR to give the user the option to add translations to countries (or heaven offend for WHMCS to do it automatically) - it would require structural changes... and with an FR with 2 votes, that they think is a solved problem, nothing will happen.

20 hours ago, MrGettingRatherFrustrated said:

I have a very dirty and nasty mechanism which allows me to actually use a different file for these elements based on the language chosen

from a quick look at the site, it does seem a quite convoluted solution... the buggy redirection on language change would drive me nuts because it's not redirecting back to the original page.

20 hours ago, MrGettingRatherFrustrated said:

it's sounding like overwriting and reordering the dist.countries.json is going to be the easiest although most tedious option and I'll have to reinstate the modified files post upgrades 

don't over-engineer solutions with WHMCS if you can avoid it.

if it were me, i'd just use Language Overrides to give you a simple means to add translations for the countries in each separate language overrides file and then to use a hook to loop through the relevant array, replace the country names with the translations (if they exist), sort the array and return it back to the template... for any given array,  that's going to be no more than a dozen lines of PHP code.

... and then with regards to the language overrides (e.g French)...

<?php
$_LANG['country']['AU'] = "Australie";
$_LANG['country']['DZ'] = "Algérie";
$_LANG['country']['BE'] = "Belgique";

the time-consuming pain of this would be writing/finding the translations - but I suspect that you've already completed this step in your own solution.

one other point that you'll need to appreciate is that WHMCS doesn't store a client's country by name (original or translated), it stores the country code (GB, FR etc) instead - so every time that it pulls the client's country from the database, it's going to use the default name value for the country code and not the above translation - so that will be occurring in the invoices/quotes templates, client's profile sidebar and maybe a few other places.... they could all be fixed in various ways.

tbh I can't recall many questions over the years where someone actually wanted to bother translating country/states per language... the OP of that request didn't post in the forums about this AFAIK, and after quickly looking at his site, he hasn't translated the countries yet.

[MrGettingRatherFrustrated]

"From a quick look at the site, it does seem a quite convoluted solution... the buggy redirection on language change would drive me nuts because it's not redirecting back to the original page."

Yep, that is also one of the major issues to be fixed - you do have a PM in relation to that and a few other things 🙂

The problems with the WHMCS crappy language=xyz is approach are well documented  - using the /local-code/ in the start of the URL is how I'm getting round that which then allows me to essentially make any element under that path unique.

I have a fundamental (philosophical)  issue with the concept of hooks and overrides for much of this - executing secondary code (hooks) to alter the behaviour/results of the primary code already executed seems simple lunacy for anything other than a tactical bug fix, similarly loading second config files to overwrite the content of the primary config file although less of an issue just shouldn't be necessary and is simply because a suitable update mechanism hasn't been designed and implemented - surely adding rows to text files isnt beyond the capability of the WHMCS developers ...

Anyway, if you could have a look at the message I have sent you regarding some dev work and give me a shout it would be appreciated as I would like to get the language selector behaviour addressed!

Edited February 20, 2021 by MrGettingRatherFrustrated