• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Best Practice for Multi-Lingual Support

Which is better:

$lang['my_content'] = 'Content with <a href="http://www.w3.org/Amaya/User/HTML-elements/inline.html">inline markup</a>';


// the %s would have to be built outside of the language file; "inline markup" would still come from the language file, though
$lang['my_content'] = 'Content without %s';

A purist might argue that the language files should ONLY contain language items; no markup whatsoever. This adds a layer of difficulty when having to deal with inline markup (declaration of another language variable, having to construct the markup outside of the language file, etc.).

Perhaps there isn't a problem with mixing content and markup in the language files -- if it will simplify complexity of code.

Are there any suggested best practices for this issue?

You're not getting a lot of response because there really isn't a "best practice". Like you say: only purists would argue about this. It's really up to how you want it.

I guess you could put all your markup in micro views and load them with $this->load->view($lang.'-view, $data, TRUE) in a string to then echo them out in your actual view. But if it were for me, I'd just add that little bit of markup in my language files...

The idea of language files is to take the strings out of the html code to make it easier to change the strings if needed. Why would you want to add markup to those strings??


It's the inline markup that creates a problem. If the markup was just going to surround the string, then I would suggest keeping the language files "pure" and not have any mark up in it.

But what is the best way to deal with content that has inline markup? For example:

"Of all the colors, <strong>pink</strong> is my favorite color."

Do you suggest the following:

$lang['favorite_color'] = 'pink';
$lang['favorite_color_statement'] = 'Of all the colors, %s is my favorite color.'

You would need to get $lang['favorite_color'], wrap it in <strong> tags, then put it in $lang['favorite_color_statement']. What if there were multiple nestings of inline markup? Can you imagine the headache?

If it was me i would make the string simpler instead of using placeholders in the language file. So from "Of all the colors, <strong>pink</strong> is my favorite color.” i would make "is my favorite color." and then in in the view do
<strong>&lt;?php echo $fav_color ?&gt;</strong> &lt;?php echo lang('fav_color_suffix') ?&gt;
This is something you control why should you make it harder on yourself instead of making it easier?

This also creates the possibility to create a phrase_parts_lang.php and colors_lang.php files where you can reuse the colors file in other situations.

I don't think it's a good idea to change the content just to accommodate problems with inline markup. Plus, translations into other languages can cause problems you avoided in one language.

What you say is true but the idea is to make your interface as simple as possible if it has to be multilingual.
$lang['fav_color'] = "favorite color";
Says the same thing as "Of all the colors, pink is my favorite color."

I think the worst thing you can do is start creating long winding phrases. And i still have no answer why you need to add markup to a string. If it's something a user added he is going to look if it is correctly registered so you don't need to emphasise it.

Inline markup is necessary for semantics. Perhaps a segment of content needs to be emphasized, or is a link, etc. Inline markup is unavoidable.

It's not reasonable to assume you can control the content. What if the content doesn't come from you? What if the content really needs nested inline markup for semantics? The following are rough translations of our example:

"Of all the colors, <strong>pink</strong> is my favorite color."
"Sa lahat nang mga kulay, <strong>kulay rosas</strong> ang paborito kong kulay."
"<strong>Розовият</strong> е любимият ми цвят от всички."

I'm thinking this might be OK. Maybe it really can't be avoided in some cases.

If you are not in control of the content then you don't have to worry about about it. if they can change it however they like who says the want to keep the emphasising?

Having 'solid' html in a string will give you sour grapes in the long run.

Again, you are missing the point. Let's just assume inline markup is needed (meaning, no more arguments such as "who says they want to keep the emphasizing" or "[the content] is something you control "). In this case, what is the best way to handle that? Have a lot of variables just so you can keep language files "pure" or go ahead and include inline markup to keep things simple?

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.