HELP! Much of the C5 interface code not using the t function. Can't translate many important items!
Permalink
Many of the important parts of the C5 interface can't be translated. This is because items that are pulled from the database have not been wrapped in the t function in the core code.
This is not trivial: it means that core attribute names, attribute types, job names, descriptions and run results, and worst of all block names(!) are all stuck in English. There may be more but I have now stopped looking.
There are so many of these items that I am unable to do what I told the client I could - which is to run the C5 admin interface completely in different languages.
Please tell me I've missed something. The documentation on the C5 site suggested that translation was not a problem.
Can anyone advise? I am facing the prospect of having to go back to the client and say I was wrong!
This is not trivial: it means that core attribute names, attribute types, job names, descriptions and run results, and worst of all block names(!) are all stuck in English. There may be more but I have now stopped looking.
There are so many of these items that I am unable to do what I told the client I could - which is to run the C5 admin interface completely in different languages.
Please tell me I've missed something. The documentation on the C5 site suggested that translation was not a problem.
Can anyone advise? I am facing the prospect of having to go back to the client and say I was wrong!
The problem is that the admin interface needs to run in two languages.
If there were just a handful of things that were always in English then this would probably be ok... but if you add up all the things that are not wrapped in the t function there are a lot!
You ask why I want attributes translated - the simple answer is because they need to be! "exclude-from-nav", "meta keywords" etc will not be understood by a non-english speaker.
If there were just a handful of things that were always in English then this would probably be ok... but if you add up all the things that are not wrapped in the t function there are a lot!
You ask why I want attributes translated - the simple answer is because they need to be! "exclude-from-nav", "meta keywords" etc will not be understood by a non-english speaker.
and you can run much of the admin interface in multiple languages .. I am already doing this.
It's just that all of those elements that come from the database stay in English.
It's just that all of those elements that come from the database stay in English.
Ok, thanks. I now understand what you need.
So, for the attributes problem, there really isn't a solution currently although you could customize one just for you. In the current (released) versions of concrete5, these come during the installation process from SQL script files. These can be found from
So, you clearly see that they are there in English.
However, wrapping text that come from database inside t() function is not sufficient to solve your problem. 100% of the translation programs that read through the PHP files and search for t() functions just find the string inside that. So, in your code if you would have a function call like this:
ANY of the translation programs would NOT provide the string stored in the database for you to be translated.
However, this issue can be solved with some customization. I'll tell you that you need to open the hood and do this yourself to be able to achieve this.
What I'd do is adding a custom PHP file for the translations you need JUST so that the translation programs can find the strings. So e.g. in /config/custom_translation.php I'd just write:
After that, just parse through the PHP files with a translation program and it would add those strings to your translated strings.
You can even add these kind of custom translation files to your site in folder:
Where xx_XX is the locale.
Now, after this if you have in the code for the database strings like this:
It WOULD actually provide you the translations if $databasecontent contains some of those defined custom strings.
For overriding e.g. the attribute names in the Page properties, you'd need to do an override for the file:
And add the attribute names into the t() function.
So, there is a workaround BUT it's not as easy as it could be.
Br,
Antti
So, for the attributes problem, there really isn't a solution currently although you could customize one just for you. In the current (released) versions of concrete5, these come during the installation process from SQL script files. These can be found from
/concrete/config/install/no_sample_content.sql (no sample content selected) /concrete/config/install/sample_content.sql (sample content selected)
So, you clearly see that they are there in English.
However, wrapping text that come from database inside t() function is not sufficient to solve your problem. 100% of the translation programs that read through the PHP files and search for t() functions just find the string inside that. So, in your code if you would have a function call like this:
echo t($databasecontent);
ANY of the translation programs would NOT provide the string stored in the database for you to be translated.
However, this issue can be solved with some customization. I'll tell you that you need to open the hood and do this yourself to be able to achieve this.
What I'd do is adding a custom PHP file for the translations you need JUST so that the translation programs can find the strings. So e.g. in /config/custom_translation.php I'd just write:
<?php t("Attribute Name"); t("Other Attribute Name"); t("Third Attribute Name"); // etc.
After that, just parse through the PHP files with a translation program and it would add those strings to your translated strings.
You can even add these kind of custom translation files to your site in folder:
/site_root/languages/site/xx_XX.mo /site_root/languages/site/xx_XX.po
Where xx_XX is the locale.
Now, after this if you have in the code for the database strings like this:
echo t($databasecontent);
It WOULD actually provide you the translations if $databasecontent contains some of those defined custom strings.
For overriding e.g. the attribute names in the Page properties, you'd need to do an override for the file:
/concrete/elements/collection_metadata_fields.php
And add the attribute names into the t() function.
So, there is a workaround BUT it's not as easy as it could be.
Br,
Antti
And by the way, I think your point is really great!
There's a project for someone to provide a pull request for this issue in github. :)
Maybe you'd be up for doing a pull request for the core if you need it?
Antti
There's a project for someone to provide a pull request for this issue in github. :)
Maybe you'd be up for doing a pull request for the core if you need it?
Antti
Thanks for your replies. Very helpful.
I'll look into your ideas.
I'll look into your ideas.
Ok, great that I could provide some help, it's a tricky question!
One more point, if you use this folder for storing the custom site-specific strings:
In the code you also need this at some place:
This would look for the file in the site-specific translations directory and add those translations for the localization functionality.
Antti
One more point, if you use this folder for storing the custom site-specific strings:
/site_root/languages/site/
In the code you also need this at some place:
$loc = Localization::getInstance(); $loc->addSiteInterfaceLanguage("xx_XX");
This would look for the file in the site-specific translations directory and add those translations for the localization functionality.
Antti
Of course I will still have to over-ride some core files (or even hack them directly if they can't be over-ridden) in order to wrap the t function around the db output.
Yes, I think you should be able to override them properly without hacking.
Not sure, but I think you should be able to do that.
Not sure, but I think you should be able to do that.
A further note: It's been stated that if you do a fresh install with a language pack at the ready then the block names will be translated during installation. This appears to be true - I can see block names in the .po file... but the core attribute names are not. So even the fresh-install route would appear to leave some things stuck in English.
But the real problem is that without t function wrapping of the interface elements that come from the db the admin interface can't run with switch-able languages
But the real problem is that without t function wrapping of the interface elements that come from the db the admin interface can't run with switch-able languages
You will be happy to know that there are a ton of pull requests and commits for t() functions for 5.5 right now.
Are you setting up the site for a specific client that needs it in a specific language? So, does your client need it with different languages.
I think that the most common case with c5 sites is that you don't have a big multilingual team using it in different languages. Although this could also be achieved.
I think setting up the block names etc. should be up to the theme developer, so you could modify the theme or add your own theme with the block names that your client wants to.
For the attributes etc. why do you need them in different languages? Can you please provide a bit more info (=what you're trying to achieve) and I think there will be many c5 developers eager to find a workaround for your problem.
I think it's possible to accomplish what you need (although the multilingual solution in c5 is not perfect currently). I would just like to know a bit more about your problem first. Imagine if your maths exam just said "solve the problem, please!" and you would have a couple of hours to return the paper without the exact problem specified. :)
Br,
Antti / Mainio