did this work before 3.7?

Yes

Related to this PR #13407 perhaps

hmm the only change done there was:

old

$contents = file_get_contents($filename);
$strings = @parse_ini_string($contents);

new

$strings = @parse_ini_string($filename);

Could this be the issue? can you check @Radek-Suski ?

I don't think so. I had this already with the first beta but I thought it something I screwed in my code. I was searching in 3.6 and there is no parse_ini_file at all. Unless I am blind

No, sorry. I was wrong. So I have no idea why it worked before

did you try the change from above? So you have the string vs the file name as parameter?

it cant be because of the brackets as many core strings have brackets

Ahhh. Let me check

No, parse_ini_string doesn't work for me either.

root@sigsiu-pi:~# php -r "parse_ini_file('/www/Neo/language/de-DE/de-DE.com_sobipro.ini');" PHP Warning: syntax error, unexpected '(' in /www/Neo/language/de-DE/de-DE.com_sobipro.ini on line 26 in Command line code on line 1 PHP Stack trace: PHP 1. {main}() Command line code:0 PHP 2. parse_ini_file() Command line code:1

This is really weird.

did the exact old code work?

$contents = file_get_contents($filename);
$strings = @parse_ini_string($contents);

Ok. I think I see what's the issue is. When I restore the code back:

`
$contents = file_get_contents($filename);
$contents = str_replace('QQ', '"""', $contents);
$strings = @parse_ini_string($contents);

`

It works fine. I have QQ in this file so I guess it is rather this problem and not the brackets

we still have QQ in the core

@Radek-Suski did it also work if you remove the seccond line and just use the code i proposed above?

No. It doesn't work then. Let me check Brian. Maybe it is something wrong with our files then

I would take a look but sobi wont install for me at all

Please wait, checking requirements ... Wait please ... 1 processes are still running

parse_ini_file() respects constants that have been loaded when a file is parsed. So the manual parsing/replacing that was used in 3.6 is unnecessary.

Ok, I think we found it. The problem with QQ is that TransiFex apparently is adding some strange construct to it:

SP.IMAGE_UPLOADED_CROP="Die Datei \"QQ"%s\"QQ" wurde hochgeladen. Klicke auf die Bildvorschau um den sichtbaren Bereich anzupassen."

It worked with the previous method (replace) and with the INI_SCANNER_RAW. So basically the issue is the trash coming from Tx. Not sure what to do about it.

as we need to care about B/C and you are not the only one that uses Tx i think we should revert that smal part and deprecate that behavior for 4.0

I always manually went through my files after a tx pull and removed the crap. I don't think there's anything for core to do with that.

Thanks for confirming its not a core issue.

I always manually went through my files after a tx pull and removed the crap.

do you think every 3rdparty dev is doing that? Are we alloed to break this extensions in 3.x?

I am not sure if everyone would have such problem. I just went through our lang files with Sigrid. We are not using QQ in our en-GB files but escaping quotes: \ " %s \ " and TransiFex makes out of it \ \ " QQ " %s \ \ " QQ "

w/o blanks. AFAIK escaping quotes signs is valid in INI file (for PHP at least). It could be indeed that other 3rd party devs are going to have similar issues. Not sure

what about reveting it for now to keep b/c and remove it with 4.0? I see no issue with that.

It depends. As long as both the 3.6 workflow and 3.7 (basically the difference between manually parsing a file contents then using parse_ini_string() and just using parse_ini_file()) allow the same values in a string (which should be validated against our debug code in JLanguage), there is no B/C break. But if there is such a core behavioral change between parse_ini_string() and parse_ini_file() then yes it must be reverted. To be honest, it looks like the change just makes the parser more strict, the screenshot shows what really looks to be a questionable INI string (which looks to be confirmed by the command line statement posted above it).

Yes my only point is this comes out per default of TransiFex and IIRC a lot of extensions use TransiFex for translations

But, the Transifex files as dumped are not valid INI files as they fail PHP's parser. It only passed previously because the file contents were being manipulated by us in our code. So I do not see this as a B/C break as we were allowing files that were not proper INI format to be read and now the parser is more strict to the INI format structure (at least as PHP uses it).

This is an issue with Transifex that they must address.

It's honestly not much different than the Registry JSON formatter being more strict about throwing errors with broken JSON strings versus blissfully returning a null value and devs/users thinking things were working with their expected data.

you could put a note in the docs i guess if you think it will effect others

sure. but don't b/c means something like works with (nearly) no code change in the next version? I'm not affected and don't care but don't we try to not be the one that are blamed for any issue on 3rd party extensions.

It depends on your interpretation of B/C. If the resource was previously obviously broken (as can be confirmed by Radek's inline script) and we make a change that stops accepting a broken resource, to me that's not a B/C break.

I agree with Michael. It's rather Tx issue and ours as we didn't realised it's producing invalid language file. If we could a note it should be enough. I wouldn't say it's a B/C issue. It was broken before but worked so we couldn't see the bug.

Than this is going to be a we have fixed this bug. Why did you not tested your extension on RC releases.

Definitely should be noted in the FAQs.

https://docs.joomla.org/J3.x:3rd_Party_language_files_are_not_loaded please check and correct any issues if we have one.

I would not call it "third party language files not loaded", basically sounds like a big "we broke your stuff and we don't care". "Changes in language file loading" is more human friendly.

Page renamed https://docs.joomla.org/J3.x:Changes_in_language_file_loading

Thanks you @Sandra97

This is an issue with Transifex that they must address.

Has anyone alerted Transifex to this thread please?

@Radek-Suski
Just an additional comment - If you would use single quotes like '%s' "instead of \ " %s \ " , you won't have this problem with Transifex. I think html entities do work, too.
But even if the source language files use single quotes, some translators used "_QQ_" within their translated strings. Transifex translates these into"_QQ_"_QQ_"_QQ_", which is not tolerated anymore and results into parsing errors with Joomla 3.7.0.

There are quite a few extensions with this kind of problem now. I wonder if it would make sense to replace all the "_QQ_" in Joomla language files with single quotes or html entities for double quotes. If I remember correctly, the "_QQ_" was a Joomla 1.5 specific invention to escape double quotes and is deprecated since a long time already. If I'm not mistaken, that would not create a backward compatility issue

For the Joomla 3.7 release I updated all my extension language files from "_QQ_" to \" which as mentioned appear as\"NOT\" in the Transifex editor window but when downloaded become \\"_QQ_"NOT\\"_QQ_" To fix this in my language extension that downloads and creates my extension language packs (Similar to CTransifex) I did a string replace just before the data is written to file like this:

$file['data'] = str_replace('\\\\"_QQ_"', '\\"', $file['data']);

Now my language packs are now correctly being loaded.

For CTransifex uses you can do a similar change by adding the line above just before line 78 of:

administrator -> components -> com_ctransifex -> helpers -> package.php

I hope that helps any devs out there and I will also reach out to the dev of CTransifex.