Change the default language : successful Proof-of-Concept

[er314]

This is the follow-up to request #570 ("Add the capability to change the website default language, in the admin")

-> For exploration, I have implemented a Proof-of-Concept of the "change the default language" feature,
with a quite simple approach, detailed below.
This is certainly not the smartest implementation, and it is certainly not handling all corner cases yet, but this is for concept proofing. This is hand-crafted without AI, for better or worse :-)
I hope this will eventually make "change the default language" feature a reality, as the current solution "just reinstall, reconfigure & repopulate from stratch" cannot be Processwire final word.

This Proof-of-Concept is available on a Processwire fork on github, here : er314/processwire@94de4e3

New logic :

• With the new logic, I get a quite well functioning system :

  • testbed website is bi-lingual, english (default) + french :
    "/" is the english root path, and "/fr/" is the french root path
  • -> there's no change, as long as the initial (= install-time) default language (english) is kept unchanged
  • now let's switch default language to french :
    . move "fr" language as 1st in the list of languages, before "default" (via drag & drop in System / Setup / Languages)
    . in "/" page settings, set "/" as the french root path, and set "/en/" as the english root path
  • -> now,
    . the frontend for "/en/..." fully renders in english (fields contents & code __() translations),
    . the frontend for "/..." fully renders in french (fields contents & code __() translations),
    . frontend page rendering in english uses the french field value as fallback, whenever the english value is not populated
    . the admin renders french as 1st language (mandatory), english as 2nd (optional)
    . the admin fields constraints of a Page are enforced on the french (now-1st language).
    . in attachment, you will find various screenshots illustrating this behavior.

• How :

  • No breaking change (no change at all) to the DB scheme : there is still the initial language data (not languageId-suffixed), and the other languages data (languageId-suffixed)
  • In addition to Language method isdefault(), there is now method isInitial() : this returns the static, install-time defined default language. This new method replaces isDefault() usage at many locations in the code : everywhere this new semantic makes sense = everywhere the code wants to access DB data.
  • Method isDefault() now has new processing : it no more returns the initial, install-time defined default language ; instead, it returns the default language (1st language) currently assigned in the admin.

• Notes :

  • For all existing multi-lang websites, where default language is not altered in the admin, isDefault() still returns the same language as it used to be, which is the same language as isInitial()
    -> Full backward compatibility is ensured. Things start to differ whenever the default language is changed in the admin.
  • By default, the languages are sorted with initial language equalling default language
    -> This provides full compatibility for existing websites
  • Default language can be changed, by changing the sort order
    -> The language moved on top is now the default language
    note : this method for setting the default language (compared to a radio button selector) has the advantage that the iterator over languages is outputing the languages in the correct order, without any code change.
    + UX-wise, it's cristal clear : the languages are sorted as in the admin, including for the 1st language as 1st = the default
    -> This activates the new processing

Known issues & limitations of the current implementation :

• In the settings tab of a Page, checkbox "Active?" now also applies to the initial language, when it's not the default language. The name of this input field is "statusXXXX" for non-initial languages, and "status" for the initial language. Problem : "status[]" is also the name for the Status settings of this same form. So we now have a naming clash here.
  (until now there was no problem, because the initial language was also the default language, therefore it never had the "Active?" checkbox).
  see "// TODO glitch" code
  -> impact : can't save changes to the page Status settings
  -> fix : fixing this unlucky side-effect is obviously out of scope of the Proof-of-Concept

• Even though in the default config (with "default" lang kept at 1st position) there's no regression to expect, as soon "default" is no more 1st, some issues may arise,
  . due to using oher 3rd party multilang fieldtypes, not yet adapted to the new scheme ?
  . due to website custom processing making use of the "name123" legacy scheme with the legacy (now outdated) logic ?
  -> so I guess that the developer shall have the capacity to decide to enable (or not) this new behavior, via a new setting e.g. $config->enableChangingDefaultLang = false; // default disabled (when false, maybe this should prevent "default" language from being replaced at 1st position in the admin ?)

• Proof-of-Concept does not support yet renaming the initial language to something else than 'default'
  e.g. $language->isInitial() and $languages->getInitial() are currently implemented thanks to this now-deprecated name, instead of using some install-time persistent data

Not thoroughtly tested :
. all
Not tested at all :
. when a language is added/removed in the admin
. non-reg esp. with single language and without multi-lang extension
. admin constraints enforcement, besides the required values for default lang

The code is here on github : er314/processwire@94de4e3

The below screenshots illustrate the new capability.