Would it not be better to use $lang->load to include the existing language file than to create another set of strings

Would it not be better to use $lang->load to include the existing language file than to create another set of strings

@brianteeman I had asked about this and got feedback from @zero-24 that I should not make the joomla update model depend on the installer's language strings, see e.g. #29884 (comment) .

Obviously I disagree but if anything then both components should be using a global string. Maintaining two identical sets of strings is just not right

@HLeithner @zero-24 Please advise regarding previous comments. I'll do whatever will be decided.

@brianteeman If you compare the strings used without and with this PR, you will see they are not all the same. This PR here changes some of then which talk about the installer so that they talk about Joomla Update. So at least for those global strings will not make sense.

It should be ok if the updater has it's own strings especially if not every thing is exactly the same.

I agree with @HLeithner you might even what to give a different message in com_joomlaupdate maybe in non en-GB languages. The thing about not depending on com_installer is it should be possible that com_joomlaupdate can be released as standalon so it should be done with as less as possible dependencies to other components in my opinion.

I agree with @HLeithner you might even what to give a different message in com_joomlaupdate maybe in non en-GB languages. The thing about not depending on com_installer is it should be possible that com_joomlaupdate can be released as standalon so it should be done with as less as possible dependencies to other components in my opinion.

@zero-24 This PR only solves it for the model, where the installer language strings were not translated. But there are still installer language strings used in the default_upload.php view. Those strings are translated well, so I did not see the need to change them, too. @HLeithner Is that ok, or shall I handle them too with this PR?

I'm unsure... because having duplicated strings are look wrong but using strings from an other component doesn't make sense either....

@brianteeman @HLeithner I've moved those untranslated strings fixed by this PR and being the same for com_installer and com_joomlaupdate to global language strings and added deprecation comments to those language strings in the com_installer language file. For consistency I've also moved two description texts which belong to other two moved texts, even if those descriptions are (currently) only used by the installer. The installer PHP I've changed to use the moved strings.

@brianteeman I'd be happy if you could check what I've done with the strings, especially check the deprecation comments in the installer language file and if necessary suggest corrections. Thanks in advance.

PR is still draft because I have to write testing instructions and I'd like to wait a bit, maybe PR #29881 will be merged soon, and this will make testing of this PR here easier. But it can be already reviewed.

@brianteeman Could you check my replies to your review comments above and make suggestions? Thanks in advance, and thanks for review so far.

@richard67 I already did - or am i missing something

weird they only just showed up

@brianteeman Thansk for review. All done. Stay tuned with testing instructions and draft status removal. I need a break.

It seems the issue with these untranslated strings has been solved meanwhile, since on a current staging they are all translated when I add some debug code to check that.

I've just checked that.