Thanks will test this tomorrow

I have tested this item ✅ successfully on 4bbfd4c

I have tested this issue successfully.

While testing, I noticed some of the language flags were missing for the following Language Packs:
German AT (de-AT)
German LI (de-LI)
German LU (de-LU)
German CH (de-CH)
Sinhala (si-LK)

Imho, we should only add a content language when the site is multilang. No use to get that manager crowded otherwise.
I confirm the flags above are missing.

Reggarding the missing flags see #11868

@inforgraf768 you have repeatedly stated that you can have multiple content
languages without a site being multilanguage. Do I have to list all the
reasons and times you have stated that.

Imho, we should only add a content language when the site is multilang. No use to get that manager crowded otherwise

Nobody will install all this languages. Anyway imho there are few cases that a languages is installed without the intend to have it on the site. I reaaly don't think it's better to add that it conditiion that can lead to some confusion. From ux I prefer to always have the same behaviour.

This was because Elin was using that field for school noting, indeed.
There are a handful of people over the world using that field for other purposes than multilang.
These do know what thay have to do.
No use therefore to do it systematically.

? for always creating the content languages. I doubt the manager gets crowded due to this and for the few sites where that would be the case it is simple to delete the unpublished languages (if the owner even cares) :smiles

So are you now removing your objection to not displaying the language
column and field in a non multilanguage site.

So are you now removing your objection to not displaying the language column and field in a non multilanguage site.

No, because some people may use it... Please stop this.

@andrepereiradasilva
Once a site is installed, the string
INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME is not available anymore

Just trying to understand your objection @infograf768 as it seems
completely illogical and contradictory.

I'm all for this pr. It's a massive improvement and removes a major area of
confusion and a common cause for error

@brianteeman
https://en.wikipedia.org/wiki/Backward_compatibility

Now you are really grasping at straws as all your previews reasons have
been rejected. On what planet does adding a new feature break backwards
compatibility. If you have serious reasons then please state them. If not
then please let thoae that want to improve Joomla and make it easier to use
do so

I was speaking of the language field you are insisting on not displaying, not of this PR. Obviously.
I welcome apologies.

I have tested this item ✅ successfully on 4bbfd4c

Works great - this will save me so much time and frustration when I end up making an error on the complex content-language form and it doesnt work

Once a site is installed, the string
INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME is not available anymore

will correct that. What field from site language manifest should i use them for the native language ?@infograf768

Only one safe solution: use also $siteLanguageManifest['name']

ok done

I have tested this item ✅ successfully on 661ff82

RTC, thanks!

@infograf768 did you test joomla install wiwth multilanguage content.
It is a RFC because i didn't test that.

Installation is working fine as it does not use the code in this PR.

I remarked something though:

It looks like we do not throw an error in installation in case of problem. I mean what we have in this PR JLIB_INSTALLER_WARNING_UNABLE_TO_INSTALL_CONTENT_LANGUAGE="Unable to create a content language for %s language: %s"
Which is not present in Installation.
https://github.com/joomla/joomla-cms/blob/staging/installation/model/languages.php#L732-L741

This would require some RFC and adding that same string in installation ini in the group ;Framework strings necessary when no lang pack is available
or further down where we have JLIB_ errors.

If you want to refactor installation for the possible error, I suggest to make a new PR.

If you want to refactor installation for the possible error, I suggest to make a new PR.

No, i don't want to refactor anything, but thanks. ?

Actually installation uses this code because it installs languages packages (https://github.com/joomla/joomla-cms/blob/staging/installation/model/languages.php#L178) and for that uses this code (IIRC). But in install you also manually create contetn languages (https://github.com/joomla/joomla-cms/blob/staging/installation/model/languages.php#L741).
so i didn't test yet, but there's a possiblity of an error here because it will try to install content languages already installed (when the language package installed).

Just found out the error is thrown in the controller for installation...
See /installation/controller/setdefaultlanguage.php line 141

ok should be fixed on install now too.
Please remove RTC and test on installation too.

hint:

• one tab in /installation/?view=languages (install)
• one tab in /administrator/index.php?option=com_languages&view=languages (check)

FILE: /home/travis/build/joomla/joomla-cms/installation/model/languages.php

FOUND 1 ERROR(S) AFFECTING 1 LINE(S)

734 | ERROR | Expected 2 spaces after the longest variable name

hmm
Tested new installation as multilang:
I get weird results:

Look at the Native Title for German (CH) English (UK) => BUG, as well as URL Language code for German (DE) de-de vs German (CH) de
This last one is due to the alpha order of the 2 German packs. Not a too big deal but weird.

The Native title issue also exists before this PR...

And there is a good reason for that: we do not have an installation ini file for these de-XX packs and therefore no native title string. It is using the default en-GB one:
"INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME="English (UK)"

That, before and after this PR.

It is indeed not necessary to have installation ini files for these packs as it may confuse browsers who look only at the xx part of xx-XX. This is why there was an agreement between nl-NL and nl-BE TTs to not put any installation nl-BE.ini in core.

I therefore suggest in this case to not replace by the default English but check if the installation ini file exists for the language and, if not, use the non-native language name <name etc..

Another remark concerning the URL Language Code.
Before this PR, we do not get a de but all de-XX content languages get de-xx code:

I think it is better.

Ok will check

FILE: /home/travis/build/joomla/joomla-cms/installation/model/languages.php

fixed

Look at the Native Title for German (CH) English (UK) => BUG

Should be fixed, now uses always site site xx-XX.ini name var for both titles.

s well as URL Language code for German (DE) de-de vs German (CH) de

still have to check that

ok so improved code

as well as URL Language code for German (DE) de-de vs German (CH) de

The system can't tell what in the "main" language for that language for instance is fr-CA or fr-FR ? Waht the system does is the first you install gets the two letter sef fr the second will get a lang code sef fr-xx

So, IMHO this is ready for testing.

@brianteeman and @infograf768 can you please test again on multilingual installation and on admin language install?

I disagree with this solution as it does not use the native language name when available when installing Joomla as multilang.
It was only a matter of checking if the language got an installation ini or not and use the site language name when not.

@infograf768 for consistency, the behaviour when installing a language package must be the same in both cases. That's why i move everything to JInstallerAdapterLanguage.

The only thing the installation does different is after installing the language package and thus installing the unpublished content language, it publish those languages.

So i recommend that language string "native title" to be in the site language xx-XX.ini file of the language packs, instead of being in the installation xx-XX.ini.

That way we would use it here https://github.com/joomla/joomla-cms/pull/11867/files#diff-99e88c8b646138a6bf0ff9c3246356b3R314, no matter if you are on installation or admin backend installing a language.

If you agree we can create a new language string in site xx-XX.ini for the native title (if there is not one already) and that would be used there.

on second tough, it would be even better if the native be on the language site/admin manifests files itselfs.

so i have been investigating the title ...

so, there a lot of language titles!

Example for Arabic unitag

• In the update server xmls
  • https://update.joomla.org/language/translationlist_3.xml

<extension name="Arabic Unitag" element="pkg_ar-AA" type="package" version="3.6.1.1" detailsurl="https://update.joomla.org/language/details3/ar-AA_details.xml"/>

• https://update.joomla.org/language/details3/ar-AA_details.xml

<name>Arabic Unitag</name>

• The language package manifest (/administrator/manifests/packages/pkg_ar-AA.xml)

<name>Arabic Unitag (العربية الموحدة)</name>

• The admin client language install manifest (/administrator/language/ar-AA/install.xml)

<name>Arabic Unitag (العربية الموحدة)</name>

• The admin client language manifest (/administrator/language/ar-AA/ar-AA.xml)

<name>Arabic Unitag (العربية الموحدة)</name>
[...]
<metadata>
    <name>Arabic Unitag (العربية الموحدة)</name>

• The site client language install manifest (/language/ar-AA/install.xml)

<name>Arabic Unitag (العربية الموحدة)</name>

• The site client language manifest (/language/ar-AA/ar-AA.xml)

<name>Arabic Unitag (العربية الموحدة)</name>
[...]
<metadata>
    <name>Arabic Unitag (العربية الموحدة)</name>

• The installation client language manifest (installation/language/ar-AA/ar-AA.xml)

<name>Arabic Unitag (العربية الموحدة)</name>
[...]
<metadata>
    <name>Arabic Unitag (العربية الموحدة)</name>

• The installation ini language variable.

INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME="اللغة العربية بالكود الموحد"

Conclusion: unfortunately the only native title is on installation language, wthat i can't use in the backend install languages.

IMO, this native title should exist also in the site language and in the admin language.
Why not add it to the 3 (instllation, site and admin) languages manifests?

For instance having:

<name>Arabic Unitag (العربية الموحدة)</name>
[...]
<metadata>
    <name>Arabic Unitag (العربية الموحدة)</name>
    <native_name>اللغة العربية بالكود الموحد</native_name>

Adding a metadata is certainly a clean solution, but for 4.0 imho.
In the meanwhile, please re-add, even if not consistent, the use of the INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME when installing Joomla and the ini file is present. Without it, I would consider this as a regression (small, yes, but still...)

Here is what I did in the installation model to get
---1. the nativelanguagename when available in the installation ini file
---2. the language name when
-----A. The ini file is not present (variations of German) => corrects bug
-----B. The string itself is not present in the ini file (in the example below I took off the string from Sinhala). => Corrects bug

// Load the native language name.
        $installationLocalisedIni = new JLanguage($itemLanguage->language, false);
        $nativeLanguageName       = $installationLocalisedIni->_('INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME');

        if (!file_exists(JPATH_INSTALLATION . '/language/' . $itemLanguage->language . '/' . $itemLanguage->language . '.ini'))
        {
            $nativeLanguageName = $itemLanguage->name;
        }
        else
        {
            $strings = file_get_contents(JPATH_INSTALLATION . '/language/' . $itemLanguage->language . '/' . $itemLanguage->language . '.ini');

            if (!preg_match('/INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME/', $strings))
            {
                $nativeLanguageName = $itemLanguage->name;
            }
        }

        // If the local name do not exist in the translation file we use the international standard name.
        if ($nativeLanguageName == 'INSTL_DEFAULTLANGUAGE_NATIVE_LANGUAGE_NAME')
        {
            $nativeLanguageName = $itemLanguage->name;
        }

Which gives

Why do we have to wait for 4.0 to add a xml field in the manifests?
To preserver the install string for now i will do both things. Will read the install string and Mark it as deprecated and will read the native title from the xml, if existe will take priority.

ok so i fix the title issues to what i think it's possible in the current scenario.
Also if the site language manifest (/language/xx-XX/xx-XX.ini) have native_name and international_name in the metadata section, those vars will have priority and be used for Native Title and Title respectively.

This should only be considered depending on decision on #11924

Also, I think we should solve the bugs in installation separately first in case these PRs are not merged for next release (as they are new features, they normally should not).

I can make a PR targeted at 3.6.3 with this code #11867 (comment) to solve the present bugs in installation.

This should only be considered depending on decision on #11924

will try fix conflicts and remove the native_title and international_title and add in the other PR when possible. so this PR will not be dependent off the other.

ok removed all non existent metadata from this.
Ready to test IMO

Can you edit the title to remove the RFC

Looking forward to testing this in the morning

thanks brian. done
when you test please test installing languages on installattion AND on backend (in this case it will produce different native titles if you delete the installation directory, but ... it seems that is expected)

Installing a new language in the admin - the message on installation is

Installation of the Estonian language was successful.

I think it should have a message that an unpublished content language has been created

Other than the comment above everything looks great to me!!!

I think it should have a message that an unpublished content language has been created

What do you propose, extending the current message to say that a content language was also installed? Can you make a suggestion?

Installation of the %s language was successful. An unpublished %s content language has been created.

?

let me see if easy to change (because in installation you create a published content language)

well that's no easy change. because that message is from admin com_installer languages model (see https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/models/languages.php#L304) and there we don't have a way to be sure the content language is successful added.

So you could get in a situation that the language package was installed, but somehow you got a problem in installating the content language. In that case you would get a warning saying the content language was not installed and a success message would say An unpublished %s content language has been created. which IMHO is not good.

So, proposal, let's leave it like it is now?

I guess people will realise it has been created for them as soon as they go
to the content languages page

On 6 September 2016 at 11:54, andrepereiradasilva notifications@github.com
wrote:

well that's no easy change. because that message is from admin
com_installer languages model (see https://github.com/joomla/
joomla-cms/blob/staging/administrator/components/com_
installer/models/languages.php#L304) and there we don't have a way to be
sure the content language is successful installed.

So you could get in a situation that the language package was installed,
but somehow you got a problem in installation the content language. In that
case you would get a warning saying the content language and the success
message would say An unpublished %s content language has been created.
which IMHO is not good.

So, proposal, let's leave it like it is now?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11867 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8eDRtCF7QviHxVSAd2gK4Uwuh3NMks5qnUZigaJpZM4JyInk
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I have tested this item ? unsuccessfully on 6abce71

Leaves orphans when uninstalling languages. Probably the same before this PR but as it gets easy to install (wrong) languages this is more likely to happen.

The process "How to make a multi content language site to a single language site" should be clearly documented. i.e. that the content language has to be deleted - not unpublished!

It's unrelated to this pr. It has always been possible to have a content
language without a language pack.

The difference is that now the language installer created the content language item. I'm only afraid that the normal single language user now has to fight with more multilingual issues.

Do you have an example of using "fictive" content languages?

"fictive" ?

@schnuti

One can prepare a full new language in Joomla multilingual without installing the language pack, by just creating a content language (unpublished) and create all related content, menus, categories, etc.
It is only when published that it will be used in frontend.

I have tested this item ? unsuccessfully on 6abce71
Leaves orphans when uninstalling languages. Probably the same before this PR but as it gets easy to install (wrong) languages this is more likely to happen.

The title of this PR is "Add Unpublished Content Language on Language Package Install", ie, there is no reference to "Remove" content languages on uninstall.

If decided like that in the future a PR can be done for remove content language on uninstall language package.

But that is not the goal of this PR.

So please if test this ok, mark as tested with success.

I have tested this item ✅ successfully on c924445

Now works correctly, string present or not in installation ini file

I have tested this item ✅ successfully on c924445

looks good too me. Thanks.

RTC. Thanks.