No Code Attached Yet
avatar nikosdion
8 Dec 2017

Short description of the issue

Language strings in Joomla! are still using "_QQ_" to escape double quotes inside the language INI files.

This was supposed to be a short-term fix for older versions of PHP (IIRC PHP 5.2 and 5.3) not being able to handle escaped double quotes consistently. As of PHP 7.0 this is no longer the case. The following behave identically:

COM_EXAMPLE_OLD_STYLE="This is an "_QQ_"escaped"_QQ_" string"
COM_EXAMPLE_NEW_STYLE="This is an \"escaped\" string"

The latter is not only more elegant but does not rely on the hidden parse_ini_string feature of parsing the INI values i.e. you can use the INI_SCANNER_RAW mode for better performance. See for some information.


Performance. It's a few milliseconds but we've reached the point where they count.

Elegance. Translation software people are all but making fun of us for having such a quaint way of escaping double quotes.

Backwards compatibility

Switching to INI_SCANNER_RAW would make it impossible to use "_QQ_". However, for the next major version (4.x) we can have a global search and replace of "_QQ_" with \" in the loaded INI file. This is still faster than using the default INI_SCANNER_NORMAL mode.

Forwards compatibility

Language files using \" to escape double quotes are compatible with PHP 5.3 and later versions no matter of the INI scanner mode. Therefore a developer changing their language files to use the new escape mode would ensure compatibility with all versions of Joomla! 3 and 4.

Documentation impact

Someone will have to change the wiki page on the language file specification. A good idea since it seems to have last been updated when Joomla! 2.5 was brand new...

Translation impact

It's a global search and replace. It takes all of 10 seconds.

Third part translation software

The project can contact major players in the translation software industry such as Transifex, CrowdIn and Weblate and ask them to update their code.

Who's gonna write this code?

Any junior dev in an evening. If nobody else volunteers then I can do it.

avatar nikosdion nikosdion - open - 8 Dec 2017
avatar joomla-cms-bot joomla-cms-bot - change - 8 Dec 2017
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 8 Dec 2017
avatar franz-wohlkoenig franz-wohlkoenig - change - 8 Dec 2017
Category Code style Language & Strings
avatar franz-wohlkoenig franz-wohlkoenig - change - 8 Dec 2017
Category Code style Language & Strings Code style Feature Request Language & Strings
avatar infograf768
infograf768 - comment - 8 Dec 2017

fyi, since i adapted com_localise to use escaped double quotes, any ini file saved does not contain any "QQ" whatever is used in en-GB. 😉

avatar brianteeman
brianteeman - comment - 8 Dec 2017
avatar brianteeman
brianteeman - comment - 8 Dec 2017

I tried to remove them all #5615 but it was rejected and i had to revert them

avatar nikosdion
nikosdion - comment - 8 Dec 2017

@brianteeman This is not what I suggested. Replacing "_QQ_" with "" will indeed work unreliably across different PHP versions. That's why I mentioned the correct way of escaping which is \" and which I have tested myself. The last two years nobody complained about me not using "_QQ_" in new language strings in my software, so there you have your field testing.

Regarding the original PR, yeah, it's vaguely related to what I am saying. However, it's not merged for reasons unknwon and it does NOT implement the RAW parsing mode which gives the performance boost. Moreover it introduces a b/c break which my proposal does not.

avatar brianteeman
brianteeman - comment - 8 Dec 2017

if i remember the issue was when there were multiple " in the same string

the original pr wasnt merged because it went out of sync and the author is no longer available and its marked needs a new owner

avatar nikosdion nikosdion - close - 8 Dec 2017
avatar nikosdion
nikosdion - comment - 8 Dec 2017

This is exactly what I am talking about. If you replace double quote underscore double Q underscore quote with a single or double instance of double quote it will not work. You have to replace it with backslash double quote for this to work. In short: you made a wrong substitution. Reverting that back to "_QQ_" at the time was correct.

Please re-read my proposal. I am giving a solution to that, I covert forward and backward compatibility AND I am telling how to improve performance without affecting existing extensions.

Anyway, I see that this is going to devolve into a discussion about something other than what I proposed. I have neither the time nor the energy to do that. If you want to fix a stupid decision from 8 years ago and improve performance I told you how. Feel free to either listen to me or ignore me. I don't care. I have stuff to do.

avatar nikosdion nikosdion - change - 8 Dec 2017
Status New Closed
Closed_Date 0000-00-00 00:00:00 2017-12-08 21:00:18
Closed_By nikosdion
avatar mbabker
mbabker - comment - 8 Dec 2017

Brian your older PR was trying to use raw quotes ("), not escaped quotes (\"). The former may have worked in some contexts, especially as browsers will try to fix things it sees as incorrect, but the latter (which is what's being proposed) will definitively work at all times.

It's the same type of issue you have in PHP using single quoted versus double quoted strings.

// This is OK
$string = 'Hello "person"';

// This is a parser error
$string = "Hello "person"";

// This is OK
$string = "Hello \"person\"";
avatar infograf768
infograf768 - comment - 9 Dec 2017

It was decided to not force TTs to modify their ini files in 3.x and keep this for 4.x

Admin: 142 instances of "_QQ_"
Site: 44 instances of "_QQ_"
Installation: 8 instances of "_QQ_" in en-GB, which makes for all installation ini files 1921 instances of "_QQ_"

Add a Comment

Login with GitHub to post a comment