thanks @richard67 btw: can you use the @return tag onla 3.4 so without zero at the end?

@zero-24 Sure, I will do so.

@richard67

@zero-24 I changed the @since tag instead, I guess you meant that.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5327.

Thanks @richard67

I love it! Clean and functional!

@nikosdion I love it clean, because I am German ;-)

But there remains some redesign to be done for being clean with hard-coded extention IDs in all joomla.

This PR here could be a starting point.

But I really hope someone will comment if something is not good.

And I hope @infograf768 will be able to test it somehow, because when the meanwhile merged other PRs for this file are applied, then the disabled update site for languages will be automatically enabled, so his test scenario will not work anymore.

He would have to merge my changes into his file used for the test.

I want to do the same here for making again a test with his error scenario, so I maybe can send him a file based on 2.4.0 alpha, having changed from this pr here only but not from the other one.

I hear ya! There's a lot of refactoring in need to be done in many, many things. It's a good thing that we all get to scratch our itches and get those refactorings done :)

I really like the code in your PR. As you said, it's a first step forward. I will add that it's a bold and good step forward. Well done!

Well, meanwhile I could test here with a 3.4.0 alpha updated from a 3.3.6, but I had to use a patched file containing not the changes from the pr for automatic update site enable.
I hope Jean-Marie can test, too. If necessary I can send him my patched file.

Just to satisfy my OCD can you change the class variable for $enGbExtentionId as I presume it's supposed to be enGbExtensionId(t->s which i presume is just a typo!)

I'll give this a proper test tomorrow tho because it looks awesome!

@wolsinge omg sure it is a typo ... (blush) ... I'll change it immediately.

Ah, and if you like the coding .. i think about making a pr to get rid of other hardcoded extension_id = 600 and extension_id = 700 or <> 700 stuff, e.g. in the updater. But I want to wait until this one has been merged so I know it is the right way, or at least some experienced maintainer tells me to go with it ;-)

As experienced maintainer I'm telling you go with it! :P

@wilsonge btw i am not an experienced php or javascript programmer .. and not familiar with modern things like github .. i come from stone age of c (no plusplus) and editor and command line and maybe a but ms visual studio stuff. but i try my best because joomla is a nice hobby ;-) and sorry for typing before in your name

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5327.

Bravo! This totally solves the issue here.
One more tester.

And I hope @infograf768 will be able to test it somehow, because when the meanwhile merged other PRs for this file are applied, then the disabled update site for languages will be automatically enabled, so his test scenario will not work anymore.

Test still work on present staging when the language update site is disabled in the new manager, i.e. by exactly following the test instructions I posted in #5320
This PR solves it.

The fix works for me too. I am not sure if I count as a tester? I didn't write the patch but it was partially based on my feedback, so...

as long as you tested ...

In this case you can set it RTC :)

Better directly merge it ! Thanks all.

As for the ID 700. That one is used in many places and changing that could easily cause issues in places where you wouldn't expect it.
It needs serious testing if you're going to deal with that. There is likely not much point in doing that since it will always be that value anyway.

@Bakual Yes, I agree for the 700, have seen this meanwhile myself. I think we should not change this.

The hard-coded 600 for the en-GB language pack meanwhile only appears once in installation/model/languages.php, and this is used for the optional step of additional languages installation at the end of the installation process.

At this point the database is filled (#__extensions and #__update_sites and #__update_sites_extensions), and en-GB language is installed.

So for this I could implement the same database query as for the en-GB language extension ID in administrator/components/com_installer/models/languages.php.