Translating DB strings (like block names and attribute names etc)
Permalink 2 users found helpful
Hey, I guess this is mainly aimed at the core team...
I'm working on a fairly high profile site for an international client. This is not the first site I've built requiring translation, but it's the first one that HAS to be perfect and needs full translation of both the site and the dashboard. Elements that aren't yet translated in the .po files are less of a concern - we have budget for translators. However, the one issue I've been consistently bumping into are strings that are stored in the db. I realize that they can be translated on the way into the db, so that the dashboard can run in a different language, but I need users to be able to select which language they wish to work in when they access the dashboard. And for this client, having attribute names not translated is not an option.
So I got looking at the problem. On the one hand, this isn't actually that big a deal for me. The t() function can handle variables just fine, as php will pass the string from the db to t() and so it will translate. So for one off installations, all that really needs to be done is for me to go through the core and wrap all the relevant variables with t() and they get translated.
As a full blown solution, however, I realize that this wont really cut it, as you need to scan the core for the t() function to extract the strings for translation and we don't want poedit getting littered with variables.
So my suggestion would be this. All variables get wrapped in tVar(). We then add a function to localization.php as follows:
This way, when you scan for strings, you wont fill poedit up with variable names, but as the attribute and block names etc. are all already wrapped in t() in their various controllers / install routines, they will get picked up and translated.
Would this work? Can anyone see any reason not to do this?
Jon
I'm working on a fairly high profile site for an international client. This is not the first site I've built requiring translation, but it's the first one that HAS to be perfect and needs full translation of both the site and the dashboard. Elements that aren't yet translated in the .po files are less of a concern - we have budget for translators. However, the one issue I've been consistently bumping into are strings that are stored in the db. I realize that they can be translated on the way into the db, so that the dashboard can run in a different language, but I need users to be able to select which language they wish to work in when they access the dashboard. And for this client, having attribute names not translated is not an option.
So I got looking at the problem. On the one hand, this isn't actually that big a deal for me. The t() function can handle variables just fine, as php will pass the string from the db to t() and so it will translate. So for one off installations, all that really needs to be done is for me to go through the core and wrap all the relevant variables with t() and they get translated.
As a full blown solution, however, I realize that this wont really cut it, as you need to scan the core for the t() function to extract the strings for translation and we don't want poedit getting littered with variables.
So my suggestion would be this. All variables get wrapped in tVar(). We then add a function to localization.php as follows:
function tVar($text) { return t($text); }
This way, when you scan for strings, you wont fill poedit up with variable names, but as the attribute and block names etc. are all already wrapped in t() in their various controllers / install routines, they will get picked up and translated.
Would this work? Can anyone see any reason not to do this?
Jon
