Improve fallback language

[Wang-Yu-Chao]

Pull Request for Issue # .

Summary of Changes

Add new reference fallback language field in options of com_languages.

"Fallback Language" field can now use global value.

Reference language itself won't have a "Fallback Language" field.

Testing Instructions

Expected result

Actual result

Documentation Changes Required

[infograf768]

If I may say (not yet tested the code): This is not a "Reference Fallback Language", but an "Associations Reference Language".

[Wang-Yu-Chao]

@infograf768
Thank you! May I ask what is the specific difference between these two wording? I basically made a global option of fallback_lang field, so it plays the role of default value of fallback_lang.

[infograf768]

This is where we indeed get to the root of the issue about understanding what this GSOC project is about or could be about.

I understood that any modification made to an item tagged to the default Reference Language will be known by the system.

In backend, when one will display the com_associations manager or edit an item which is associated to an item tagged to the Reference Language, a tag (icon or other sign) will indicate that the Reference Item has been modified pushing therefore the site Manager to update the associated item or just mark it as good to go by re-saving it for example.

The problem is the following:
The default Associations Reference Language may or may not be used as Fallback by another Content Language.
The difficulty here is that the "Fallback language" as defined for any Content Language would be in fact its Reference Language (see below concerning this wording), i.e. we would possibly get as many reference languages as Content Languages.

Example:
I have set the Associations Reference Language to en-GB by default.
I have an article tagged to en-GB and similar articles tagged to fr-FR and de-DE, all 3 being associated.

If I set the "Fallback Language" of fr-FR to default en-GB (Associations Reference Language), then any modifications to the en-GB associated item will trigger a warning: the reference item xx (tagged to en-GB) has been modified, please check that this item (the fr-FR one) is OK or should be modified too.
[This is what users expect of a real improvement to the multilingual associations. It is already not so simple to implement... Replace Article by any item that can be associated]

But If I set the "Fallback Language" of fr-FR to de-DE, it would only react if it is the de-DE xx article has been modified.

This is why I was and still am confused by the usage of the wording "Automatic Association". IMHO, it is already quite difficult to implement the functionality with ONE Reference Language. It may be much more complex to do when we have multiple possible Reference Languages(s).

As for Front end, I never considered creating associated items in specific content languages that would not be the one displayed when editing/creating an article, as this would require a user with the
knowledge or all content languages used in the site. It also requires the impossibility to create associations if an association already exists and the user is not aware of it. It is too easy to break existing associations. In any case, associations would not be possible for anything else than articles there.

At trying to understand your Google doc, I think I misunderstood what you really want to do, therefore this confusion.

NOTE: In any case the term Fallback Language does not look like it describes the functionnality. It is a "Reference Language". Fallback means in English that we make use of (swing to) something else when not satisfied with what we have.

[Wang-Yu-Chao]

@infograf768

Thank you for your reply. Sorry that the intention of this project has not been well explained yet and has caused many confusion. It's necessary to clarity the terms and expected results of this project now.

This project actually contains two main aspect of improvement. One is "fallback language". The other is "automatically create associations".

1. "Fallback language" is the idea my mentor Elisa got from this page: https://developer.amazon.com/de/docs/custom-skills/speechcon-reference-interjections-german.html.
   
   As you can see, this page tagged as German doesn't have current document in German, so it displays content in English with a hint (The yellow message box above) which tells that "This page is currently only available in English ...". So fallback language mainly plays the role of backups, and it is usually chose to be the language in which articles are updated. When articles in some language are out of date, which means they are altered in a more basic language, then admins can choose to use this mechanism at front end before they are updated.

2. As for "automatically create associations", it's just a simplification of current mechanism of multilingual associations. For an admin of a multilingual site, it's common to create items in many content languages. So we consider a modal that popups when admin clicks "save" and offers language options in which associations will be created.
   
   Since these articles are born out-of-date, before they are updated, at the front end they are shown in its default fallback language.

3. Another important part of this project is the updating and expiration of items. It's related to language hierarchy which is defined by "fallback languages". Languages that used as fallback of other languages are more basic, and "reference language" (default fallback) is the root. Items should usually be updated in reference language and items in other languages will be marked as expired (but it's optional whether to show that at the front end, which is defined by "change state" field).
   
   So we also need 1. a notification system at the back end to help expire and update items. 2. a restrictive structure of language hierarchy.

If we have associated articles in en-GB, fr-FR and de-DE, and the "default fallback language" (or we call it "Associations Reference Language") is set to en-GB, and the "fallback language" of fr-FR is set to de-DE. Then the hierarchy looks like this:

If en-GB is changed, then de-DE and fr-FR will all be expired.
If de-DE is changed, then only fr-FR will be expired. Because en-GB is more basic and this structure indicates that de-DE and fr-FR have special relationship (otherwise they can all set their fallback to en-GB).
Admins can also manually tag items as expired or up-to-date, in order to handle more complicated situations (which is rare). For example, admin wants to use en-GB as "default fallback language" (or "Associations Reference Language") while updating articles in fr-FR.

Hope this reply may help you.

[infograf768]

Hmm, sorry to say, but this is overcomplicated imho.

I have replied concerning automatic associations in the other PR as I foresee multiple issues.
#4 (comment)
and I still prefer an improvement that would mark any associated item as needing update because the item tagged to the reference language has been modified (This would show when editing any of the associated items directly and in the Managers list and in com_associations manager as I stated above.
In you accept to modify this, then we could use a unique "Reference Language" which can be set whether in com_languages ot com_associations options.

I like the idea of displaying a text in frontend (IF a parameter is set to do so and using a language constant rather than a textarea or both by using the same trick we use for setting site offline in Global Config although we may need to propose a redirect link) when one uses the language switcher and no specific association is set for the item in the language targeted.
Concerning Fallback language, it should have nothing to do with Automatic Associations and the need for update and I am not sure we even need it. It could be a simple param for each type of item: Yes would display a message and present a link to the Home Page of the target Language when no assoc is present (some associations may not be obvious. For example, we can have a category association but no menu item association for these categories.)

Should it be globally used is a matter to discussion. Maybe it should only concern articles. Don't forget that we do NOT HAVE TO create associations for everything, but sometimes just switch to the home page of another language instead.
I consider any other use as overkill. Specially the hierarchy trick because too complex to implement.

[Wang-Yu-Chao]

I'll discuss with my mentor about this, thank you!

[joomleb]

Hi guys,
trying to understand where you are going and giving my contribution based on my experience.
Seem to me that there is a bit of confusion here and some unnecessary complications.
There are a lot of small things I'm not understing here, so, please, forgive me if I mistake.
Let me to comment following this Wang Yu-Chao resumen.

Example

• In Joomla "En" site we installed Es, Fr, De languages
• Extensions > Languages > Content Languages: all languages are published
• Extensions > Languages > Installed: we set En as default Administrator language (backend) and Es as default Site language (frontend), logically default Administrator language can be different from Site language
• We enabled Multilanguage feature: plugins, modules, etc.

Take a look to the "JA Multilingual Component" free extension - video could give us interesting suggestments.

A Create default Items
I'll call Articles, Categories, Contacts, Menus, Menu Types, News Feed as "Items".
In our multilanguage example site let me say we create a new Article: PS 99.9 % the original article is always, and have to be, in the default Site joomla language.
Right now, when in frontend a user try to surf in De language, that doesn't exist yet, joomla redirect you to / show you the default language same page.

B Create languages items
Let me say that if I installed more than one language, I enabled the Multilanguage feature and I have published Content Languages mean that I want work with a Multilanguage site!
So, in my opinion a window pop-up for each item creation is not a good thing:

• really an unnecessary complication and delay when I'm creating the new item
• a language item creation and its association should be always a separated step, I'm used to prepare the original article and wait 24/48 before to publish it, and wait 1/2 days before to create the languages items (can happen to have some changes to do on the original item)

Would be more simple and useful have a "Run Associations" button in the "Components > Multilingual Associations" dashboard where I can select the item and the "Run Associations".
The "Run Associations" button will follow the settings in "Components > Multilingual Associations > Options":
--- Create automatically Associated Articles ?: Yes / No - Published / Unpublished
--- Create automatically Associated Categories ?: Yes / No - Published / Unpublished
--- Create automatically Associated Contacts ?: Yes / No - Published / Unpublished
--- Create automatically Associated Menus ?: Yes / No - Published / Unpublished
--- Create automatically Associated ... etc. ,,, ?: Yes / No - Published / Unpublished
If yes will create automatically items for all the published languages and will consider those items automatically created as published or not.

C Translate items / Populate
The "Run Associations" button should also populate the contents, alias etc. running an Automatic Translation. Always in "Components > Multilingual Associations > Options":
--- will have to set API key for each Translation Service = Here will be good add 1 or 2 Translation Services by default (like Google / Microsoft) and give instructions to developer on How to create plugins to add other "Translations Services".
--- then would be good here to establish the Automatic Translation languages, order, direction and service, like:
1 - from Spanish to English - by Google
2 - from English to German - by Microsoft
Why, because in this way I can choose the best translation service for each language, I can establish the direction for each language (translate to German could be more accuracy doing it from English than from Spanish), I can reach more languages (depending from directions could be more languages for the translation service), I can avoid the automatic translation for some languages because, for example, I can do and want do it manually...

D Associate
When "Run Associations" button is pressed and all languages items have been created, they are associated to the original post.
Now, I cannot think on an Automatic Association feature without an Automatic Translation pre-population and what you are calling "Fallback language" is nothing more than this "Automatic Translation languages, order, direction and service" settings.
Now, you spoke about the Frontend amazoon advice. Let me say, always in "Components > Multilingual Associations > Options":
--- "Item" language creation Message: Show / Hide = a message like: "this translated content has been created automatically, could be not so accurate"
--- "Item" language editing Message: Show / Hide: "the original content has been changed and the translation content still have to be checked"

E Confirmation
The massages will be shown till the Item translated has not be checked, corrected if needed and confirmed. The confirmation process need:
--- Set "Translator" users
--- Set assigned languages for each "Translator" (Could be more than one Translator per language)
--- An email notification each time a language item has been created and / or its original item associated (in the default Site language) has ben modified
--- A Frontend Translator dashboard of all the unconfirmed items (could be a frontend Multilingual Association version dashboard where only the languages assigned to the Translator are shown, and all the unconfirmed items are shown with an orange language icon)
--- So the Translator from frontend con open the item to confirm, compare it with "Reference" Item (the original language or the one that is better for him), make the modifications if needed, and confirm the translation.
--- for the Super Admin would be good add a Translator selector in the Multilingual Associations dashboard to have back the work done from a Translator, having a "new item translations confirmed" counter and a "modified item translation confirmed" counter

Are you agree ?

[jreys]

Hi @joomleb, thanks for you insights, I will reply each point in separate:

A: Agreed, that should be default behavior

B: Can you provide some better use cases of what you're trying to accomplish? I'm failing to see where you are trying to go but willing to listen nonetheless 🙂

C: It was never the idea on this project to rely on 3rd party services, so using Bing/Google Translate is a big no, if each Joomla developer wants to implement it on their sites it's up to them

D: Agree with the messages, to better notify the user which Articles/Categories/etc. need some attention

E: Not sure if this is part of the original project scope, can be a good bonus if there's time or if Wang is willing to add it after GSoC 😄

Thanks for your input and looking further for your answer 🙂

[joomleb]

Hi jreys,
thanks for your attention. I'll reply trying to clarify what I mean.
In first of all, Have you took a look to the "JA Multilingual Component" free extension - video ?
I think that is too important, because I investigated the Multilingual management problems for 6 months last year and I think that this is the most near extension to the most logical solution "to manage joomla multilingual associations", but simply is not integrated into default joomla.

Then, a multilingual process as I described mean:
--- A Create default Items
--- B Create languages items > C Translate items / Populate > D Associate
--- E Confirmation
Where, as I describe, after have configured all settings in Multilingual Associations > Options as I described, the "Run Associations" button should do B > C > D automatically.

Now, following your questions:

B Create languages items I don't understand what is not clear exactly for you:

• If I want create item associations I need in first to create the languages items "copy"

C Translate items / Populate When I create the new items I need to populate the items fields.
Okay, in case of an article item I can leave "empty" the content, but what about the article title alias for example ?
Are we creating anything that Joomla Administrator have to edit quickly (before to publish) and manually one by one ?!?
About "3rd party services": speaking about automatic Translation services say me "no" on have a "free default automatic translator" to run a pre-population is something like to say me "no" to the "ReCaptcha" plugin, to the TinyMCE editor etc.
"...When we'll cut off the "ReCaptcha" plugin and the TinyMCE editor etc. from joomla ?..."
And mean complicate the "Create Associations", doing something that cannot complete the associations process and/or have to be re-edited manually to be finished.
To associate something have to exist and existing the items fields have to be populated... Am I missing anything ?
Anyway, on my previous post I wrote: "...will be good add 1 or 2 Translation Services by default (like Google / Microsoft) and give instructions to developer on How to create plugins to add other "Translations Services"..." = Thinking to have 1 default service (like for reCaptcha and TinyMCE), but leaving to developers a good way to add their and/or 3rd party services. The most important thing, as I wrote, is to prepare the code to receive them and have good instructions on doing it !

D Associate
About "Messages": be careful, I don't mean "to better notify the user which Articles/Categories/etc. need some attention" for the Administrators, but in the frontend to notify to the users to be careful reading because that translation is not yet "checked and confirmed"...

E Confirmation
I doubted that is not part of the GSoC, but I was inspired from Wang post point 3 where he wrote:
"...So we also need 1. a notification system at the back end to help expire and update items. 2. a restrictive structure of language hierarchy..."
So I prefered to detail well my D point and add this E point adding some details because what Wang wrote is a real need to be able to manage a multilingual no one page site!
Now, again, the E point could also not be par of GSoC, but have a clear situation on where we are doing should help to coding something that will be ready for future adding and/or give to developers to complete the features on standard code...

Finally, I believe too much on collaboration.
Why not inform JA about this project and ask their experience ?!?
Do anyone have a JoomlArt contact?
JA Multilingual Component is for free, maybe they could be interested to help us here, giving us "piece of codes" and giving us the opportunity to have more time to do something more for the point E and they could be interested on developing more "Automatic Translator plugins".
What do you think about ?