👍

PHP has advanced enough that this workaround is no longer needed. Use native features as able, which means just escape your quotes. Even if the usage of the constant in core isn't phased out during 3.x since that would presumably create an unnecessary workload on translators, it should be gone in 4.0.

So this cannot be replaced in one go without B/C break.

Why do you think the change f the coreis not B/C? JText (as far as i remember) can handle both the Joomla QQ and normal escaped strings.

But as both should work after the changes too (until 4.0) i see no problem in changing it. The TT's need to do it anyway (atleast before 4.0) but they are not required to do it as it still works. So they get more time from us to change the strings and there is no hurry to do this for the next release as 3.7 still supports the current way? Or do i miss or missunderstand something?

@zero-24 if we removed _QQ_ processing now it would be a B/C break in 3.x branch. that's why i propose to remove it completly in 4.0.

BTW checked all https://github.com/joomla-extensions ini files and didn't find a single language variable using _QQ_ (didn't checked messages and banners because i think they are dead repos)

Correct messages and banners was prepared to be removed from core until the plt stopped that project. ;)

Ok than i got it correct. You are correct we can't stop processing the Joomla QQ

But i think we should remove the usage form the core language files too. And mark them not as requirement to change in the language translation files but as recommended :)

But i think we should remove the usage form the core language files too. And mark them not as requirement to change in the language translation files but as recommended :)

The only problem with that is it will force every string to be updated if you're using Crowdin or com_localise. So for 3.x it probably won't happen just because of the workload burden (nothing stops translation teams from optionally replacing it though), but as I hinted at above we just need to do it for 4.0 and not live another 5 years with that thing present.

@zero-24
Please understand that modifying so many strings will force TTs to check/modify or mark as OK (wth the QQ), all strings in core that would be modified. THis, when they use crowdin or com_localise that would mark these strings modified

And again, there are not 59 occurences of QQ but 190 (if we do count only the en-GB installation ini file among all installation ini). The number of QQ per string is usually multiple.

Note: while testing as there were indeed some changes in the treatment of ini strings displayed through js and for the href, I found out that our Alerts do NOT any more accept either the "_QQ_" or the \".
for example with
JLIB_HTML_PLEASE_MAKE_A_SELECTION_FROM_THE_LIST

@infograf768 it's 59 language variables (sorry for the confusion) which probably correspont to your 190 _QQ_ strings.

if you are referring to https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/toolbar/button/confirm.php#L90

that should not be like that, we could use:

JText::script('JLIB_HTML_PLEASE_MAKE_A_SELECTION_FROM_THE_LIST');
// and them in js
alert(Joomla.JText._('JLIB_HTML_PLEASE_MAKE_A_SELECTION_FROM_THE_LIST'));

anyway it should work like it was, so it seems to me like a regression, but not related to this

will check this

anyway it should work like it was, so it seems to me like a regression, but not related to this

Unrelated indeed. That's why I made a Note.

Is this not just a Search and replace?

The problem i see is that two weeks before 4.0 comes out we have translation teams that translate the new strings i expect that there are much strings to change (as the content is changed) than there are 59/190 strings more in that list where we know now that they needs to be changed. And this strings can be changed now without any problems so why do we not tell them (maybe in a mail too etc) and change the core to show the correct / recommended usage. That would reduce the workload before 4.0 stable. I know that they need to change / review it but what is the difference between now (small steps) or before 4.0 (one big step) ?

It is just a search and replace. But remember that every change in the core strings causes all of the translation tools (it doesn't matter what you're working with, every automated platform is going to do this) to mark a string as untranslated and force a translator to review it. So while it is indeed a simple change, it still causes a lot of extra work just to make sure that nothing changed except for "_QQ_" becoming \".

so it seems that we have somewhat consensus to do the removal of _QQ_ only in for 4.0 and deprecate it in 3.x.

ignore me... [deleted posts]

Is this on the roadmap already? If so, this can be closed.

#13451 is the final PR in the series for this item. Someone might need to take ownership since Andre has had to pull out due to other commitments.

Closing this item since there is the open PR though and the other items here have been addressed.