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 http://php.net/parse_ini_string 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.
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
\" in the loaded INI file. This is still faster than using the default INI_SCANNER_NORMAL mode.
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.
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...
It's a global search and replace. It takes all of 10 seconds.
The project can contact major players in the translation software industry such as Transifex, CrowdIn and Weblate and ask them to update their code.
Any junior dev in an evening. If nobody else volunteers then I can do it.
No Code Attached Yet
|Category||⇒||Code style Language & Strings|
|Category||Code style Language & Strings||⇒||Code style Feature Request Language & Strings|
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.
@brianteeman This is not what I suggested. Replacing
"" 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.
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
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.
|Closed_Date||0000-00-00 00:00:00||⇒||2017-12-08 21:00:18|
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\"";
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
Site: 44 instances of
Installation: 8 instances of
"_QQ_" in en-GB, which makes for all installation ini files 1921 instances of