I have no idea what you mean by

My Action: I did the update using the classic "Joomla Update" page.

The only way you should update Joomla is using the Joomla Update link from the components menu

It sounds to me like you are missing the contents of the language folder

After update, the translation of the language fails, i see only the codes instead of the translation.
In fact i see the (ugly) string/code used by JText, e.g.: MOD_MENU_SYSTEM, JSTATUS rtc

Where? In a custom plugin? In the core? What happen if you enable language debug? Any errors shown?

Is the site using a custom language or the default english language?

Had same problem.
You have to edit file - "libraries/joomla/language/language.php"
and add on line 834

            $contents = file_get_contents($filename);
            $contents = str_replace('_QQ_', '"\""', $contents);
            $strings = @parse_ini_string($contents);

like it was in Joomla 3.6.5 (before update)
then translations are ok but figured other problem with time (article create time/modify)

@Jishek
Thank you, i added your snippet and now joomla translation works fine.
My problem is resolved.

Modifying a core file without the changes being implemented in the core for everyone else is not a solution.

@jishek @fluctuate what language are you using

@infograf768 can you take a look at this please

@brianteeman I have multilang page: PL,EN,UA / PL Default

Are you using the latest language files for Joomla 3.7.0 version ?

There are invalid language files in your installation, see https://docs.joomla.org/J3.x:Changes_in_language_file_loading for more info.

of course

If it works with the 3.6.5 code but not the 3.7 code then the INI files are broken and the additional processing that we did before running the file contents through the INI processor hid the fact that the file(s) had parse errors.

My site is set on italian Language, it's not a multiling website.
The problem was global (not only on a specific component or plugin ),
Furthermore, the problem was both on back end and on front end.
I can not be more specific than that.

Yes, i'm using the latest language files for Joomla 3.7.0 version.

The problem with files are when someone are using brackets.
My Lang files looks good - checked by parse_ini_file function.
Anyway broken translations are missing from official Lang files so should be good because are updated and not modified by me.
If one Lang file is broken then one file is not loaded and rest is.
Correct me if I am wrong.

I can confirm this.
I am usinng the Dutch language in the backend. When I updated into 3.7 the Joomla Update screen turns English and stays English other screens are good.

I will investigate further.

When you update the language-pack from 3.6.5 into 3.7.0 it is solved (in Dutch).

I have exactly the same problem. I upgraded using the Joomla Update process from 3.6.5 so clearly there is a problem with the process in respect of language strings and overrides. No one has clearly said, in terms that don't need professional coding or PHP skills, how to replace or update an existing language pack, in my case en-GB.

So some simple steps please on where to get the relevant files and how to update over a current build?

The code hack above works fine as a workaround but I would rather have a standard build.

I've got the same issue, Joomla 3.6.5 to 3.7 using com_joomlaupdate, the problem is present in both the backend and frontend of the site, I've not had time to dig further into the issue.

I have exactly the same issue. My administration area was in English. With the update, the English language file is now 3.7 as well. But I only see the language strings, not the text. I have reinstalled Joomla but nothing changed.

I have a language override and there are two language override with " (quotes). I've deleted all the overrides but the issue stil continues.

I have uninstalled my current Turkish language 3.6.2 files both for frontend and backend. Now the whole site is on core English language files and the issue still continues.

I have the same problem. Also with Update und fresh clean install with full stable J 3.7

My trick: I disable parse_ini_file in php.

I have the same problem. It is actual and when installing nulled distr of 3.7 and when updating from 3.6.5 too. parse_ini_file in php enabled.

It is pretty hard to help when it seems that all the situations here are not similar (parse_ini_file disabled in some cases).

Let's make a first test. Please do the following:
Set the default administrator language to en-GB (The super Admin should also have en-GB as default)

Go to administrator/index.php?option=com_config , system tab

Enable Debug Language
Then go to bottom of the page and display "Language files Loaded"

Then post the screenshots of the result:

backend (where everything is fine)

frontend (where is not)

even core language files (updated and not modified) are not loaded on frontend

Do you use a default Core Joomla template like Protostar in frontend?
If not please test with default template.

In the Backend the lang files aren't loaded.
I have the same issue also with a fresh Joomla 3.7.0 installation.

same on beez template

All templates are from Joomla installer, not custom, used official nulled package from jooml.org website.

@infograf768 I've tested with Protostar Theme and Beez3, nothing is changed in the backend.
Also the default themes can't load the translation in frontend.

en-GB is my only installed language. Our server is running PHP 5.6.30 and SQL 5.6.35. We cannot update to PHP 7 at this time due to other services running on the server.

Debug screenshots:

shouldn't but maybe php version is the issue
my is 5.4.45

My is 5.6.13

@Jishek i've tested with 5.4.27 and 5.6.15, and there is no difference between these versions. Same issues about the translations.

I test on php 5.4.4, so that is not the issue.

As I said earlier, it looks like the issues are different for each of you.
for @Jis all is fine on back-end. Files not loaded in frontend.
for @mickelb all files loaded but not parsed (Have you checked that parse_ini is implemented for your PHP? It should have as it was also necessary for 3.6.5...)
for @Vadimes89 no screenshot provided to see which files are loaded or not.

Another question: is the admin login screen translated or not, i.e.

and for me ? )

@infograf768 , Admin login screen is not translated too

Me too; Admin login screen is not translated too

@Jishek
oops, mistaken @Bellu with you

@infograf768 My apologize, i haven't explained well my situation.

After updating from 3.6.5 both frontend and backend translations are missing.
Switching to the default themes in frontend doesn't change nothing.

On the same server i tried to install a fresh new Joomla 3.7.0, also in this case the translations are missing.

Admin login screen has the same problem.

maybe a parse_ini_file() availability problem in the server ?

@AlexRed if it is a problem with parse_ini_file() module, why everuthing is fine with previous versions of CMS? Or only since 3.7, there is a new way to load ini files?

@infograf768 @AlexRed perhaps this comment regarding transifex is relevant
#15378 (comment)

but for the Joomla eng core language file don't use transifex

Folks, please look at your php.ini for
disable_functions= "

And we were already using parse_ini in 3.6.5 indeed.

@infograf768 yep, and with 3.6.5 there are no any same problem. Problem only with Joomla 3.7

parse_ini_string() yes in 3.6.5, but also parse_ini_file() ?

My PHP INI:
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,parse_ini_file,show_source

@AlexRed it sounds like the solution. because parse_ini_file() is disabled on my hosting. But i need a time for testing, because my hosting support will make it for long time.

@mickelb please, remove parse_ini_file from php.ini and try to check.

Just on it.

That seems to have been the problem on my site.

OK, that explains then when issues are both in front and back-end.
It does not explain the OK on back-end and error in frontend for @Jishek

and ? to @AlexRed as indeed we only use parse_ini_string in 3.6.x

@infograf768 you are right, but it is need to test anywhere, will it fix problem or not, I can test and report only in 2 hours.

yes, I test it and I can confirm the b/c break, now in 3.7.0 if disable_functions =parse_ini_file no load the language file, it is ok in Joomla 3.6.5

I found this:
Line 39 class
Joomla 3.6.5: COM_JOOMLAUPDATE_VIEW_DEFAULT_NO_LIVE_UPDATE_DESC="Er is een nieuwe versie van de Joomla Update component die eerst geïnstalleerd moet worden. <a class=\"_QQ_"alert-link\"_QQ_" href="_QQ_"index.php?option=com_installer&view=update"_QQ_">Klik hier om de component te updaten</a>."
Joomla 3.7.0: COM_JOOMLAUPDATE_VIEW_DEFAULT_NO_LIVE_UPDATE_DESC="Er is een nieuwe versie van de Joomla Update component die eerst geïnstalleerd moet worden. <a class=\"alert-link\" href="_QQ_"index.php?option=com_installer&view=update"_QQ_">Klik hier om de component te updaten</a>."
Line 67 class and href

Joomla 3.6.5: COM_JOOMLAUPDATE_VIEW_DEFAULT_UPLOAD_INTRO="U kunt deze functie gebruiken om Joomla bij te werken als uw server zich achter een firewall bevindt of op geen andere manier verbinding kan maken met de updateservers. Download eerst het Joomla <em>upgradepakket</em> in ZIP-formaat van <a class=\"_QQ_"alert-link\"_QQ_" href=\"_QQ_"%s\"_QQ_"> de officiële Joomla downloadpagina</a>. Gebruik daarna onderstaande velden om het te uploaden en installeren."
Joomla 3.7.0: COM_JOOMLAUPDATE_VIEW_DEFAULT_UPLOAD_INTRO="U kunt deze functie gebruiken om Joomla bij te werken als uw server zich achter een firewall bevindt of op geen andere manier verbinding kan maken met de updateservers. Download eerst het Joomla <em>upgradepakket</em> in ZIP-formaat van <a class=\"alert-link\" href=\"%s\"> de officiële Joomla downloadpagina</a>. Gebruik daarna onderstaande velden om het te uploaden en installeren."
3.7 is not compatble with the use off "QQ"
This is why my update screen is in English ans maybe a lot off other problems.

The recommendation to ban parse_ini_file() in disable_function is an old one, from when safe mode was still a thing. It's no more dangerous than any other PHP function that reads from a file. A hosting provider that's banning parse_ini_file() now (especially after leaving file_get_contents() open) is misguided, operating from old advice that is no longer valid, and was of dubious benefit even when it was valid.

The correct solution to this is use a decent webhost who understands real world security, and doesn't rely on disabling core parts of the PHP programming language under the guise of "security"

I can confirm that a git clone of joomla-cms staging, with disable_functions=parse_ini_file causes a standard installation (right out of the box) to fail translating the string placeholders - now we have identified the root cause...

There is a bug in getIniParserAvailability that doesnt check for parse_ini_file when the comments say it does. If that bug was fixed, this would stop new installs being installed at the installation stage if parse_ini_file is disabled. But that would do nothing for the millions of sites already installed that have parse_ini_file disabled.

now to decide if:

1. Joomla wants to mandate a minimum system requirement that parse_ini_file is not disabled (https://downloads.joomla.org/technical-requirements)

2. Improvements should be made to support hosts that dont meet the (new) minimum system requirements (E.g. have disabled parse_ini_file)

Joomla already has a pure PHP implmentation of parse_ini_file in

Note the explanation in that class:

/**
 * A utility class to parse INI files. This monstrosity is only required because some impossibly misguided individuals
 * who misrepresent themselves as hosts have disabled PHP's parse_ini_file() function for "security reasons". Apparently
 * their blatant ignorance doesn't allow them to discern between the innocuous parse_ini_file and the _potentially_
 * dangerous ini_set functions, leading them to disable the former and let the latter enabled. In other words, THIS
 * CLASS IS HERE TO FIX STUPID.
 */

related to #15591 ?

Everyone, please test this PR #15620

If you want to manually quickly test then using FTP change the file

libraries/joomla/language/language.php

Line 833

And change this:

$strings = @parse_ini_file($filename);

To be this:

$strings = FOFUtilsIniParser::parse_ini_file($filename, true);

You may be unfairly pointing the finger at hosts. It was in the Joomla PHP INI file that I had the disable
"parse_ini_file" and that source was the original clean Joomla 3.6.5 build. Nothing to do with our host.

But anyway, good to see this has been resolved quickly.

Im sorry - you are wrong. This is purely a crap webhost issue.

I have enabled parse_ini_file and problem successfully solved. Thanks everyone for help!

I have enabled parse_ini_file and problem successfully solved. Thanks everyone for help!

That is the best solution :) While you are there also remove all the other disable_functions in your PHP.ini :)

@PhilETaylor - Thank you! But enabling all php functions is not a good idea, some of them are disabled for security reason)

@Vadimes89 again, a misconception purported by insecure web hosts with old, out of date mentalities.

Its 2017, you should not be disabling standard features of a programming language in the name of "security". You should be writing and distributing secure code. If a hacker can call a PHP function, then you are already compromised, disabling functions is not going to help you.

@PhilETaylor - strongly not agree with you! When we talking about Joomla and each other open-source CMS, we need to make additional protect on the web-server because, Joomla and most of components are compromised a priori. If you will develop ideal free CMS and modules for it , that can not be hacked, I will use it and enable all functions and modules. But nowadays I can see that each platform, free CMS or secret government system has vulnerabilities and can be hacked soon. So, ideal site for you - html page without any functions and styles)))

If you are hacked, then disabling core parts of PHP is NOT going to help you. Period.

So, if you will enable most unsafe PHP functions, you can be hacked with stronger probability)) Great logic!

Absolute rubbish. If a hacker can run PHP functions, you are already hacked. Its clear you don't understand security, so I'll not hijack this thread any more in an effort to educate you.

@PhilETaylor, I think that you are not a php developer at all, because if it will be so, you should be able to know that besides your code threads, there are vulnerabilities of php server, MySQL, web-hosting control panel, and even viruses on developer's PC. And after you was hacked, it is possible to create any maleficent scripts on your hosting, and one way if it will be botnet client (using enabled on server phmail, that can help to overload server), but it can be for example full server hack with full deleting of your site, DB and backups. And so, if you will be so dimwitted that you give to hackers all existing functions, probably it will second scenario. And if you will disable some functions, it can be f.e. that hacker scripts will be created but they will be safe for web-server and your sitr. Thats my own opinion, based on 10 years of web-development experience. Good luck)

I think that you are not a php developer at all

LMAO...

There is absolutely no reason for disabling parse_ini_file. It just stupid. It's a mentality of typical windows users as INI files are system configuration files in windows (or were)
And huge laugh at @PhilETaylor not being a developer :D

If to call each person who know html a developer, I agree with you!

And sorry guys, but thinking that anybody can create ideal safe web code - anyway its a great folly!

Sadly.i have had to lock.this conversation as it had degenerated to personal attacks.and.is now massively off topic

@MartijnMaandag
Nope, your issue is with Crowdin.

We are now discussing another solution with maintainers

Please test #15620