More descriptive Language String placeholder?

Question

<?LANG(no_download, 'you are not allowed to download')

instead of

$lang[no_download]

I have what I think is a better approach for embedding language strings in templates.

In almost all the PHP applications, the predominant language placeholder format is like <?=$lang['no_download']?> or {{no_download}}. Other designers/developers/translators will have a hard time deciphering what the placeholders represent without referring to the language file.

In order to make language placeholders more descriptive, why don't we include the original string together with the placeholder? e.g.

<?=lang( 'no_download' , 'You are not allowed to download this file because you have exceeded your quota' )?>

The second parameter is a dummy and thus nothing is being done to it by the lang() function.

At a glance, one might think that it is too verbose, adding clutter to the template markup. But in my opinion it is not a valid argument since the language string would've taken as much space as the placeholder if it weren't language aware.

I would like to hear your thoughts regarding this.

Answer 1

EDIT Didnt see this was tagged Smarty. Disregard my answer if you want a Smarty specific answer.

I wouldn't agree that there is a predominant placeholder format. In general, the format depends on how you handle the translations and that can vary.

Apart from that, it is not uncommon to provide the default language strings as translation labels. For instance, in the Zend Framework manual, this is part of their usage example. Nothing wrong with that if your translation adapter supports that. If it requires IDs, then it's not an option.

Personally, I prefer IDs and try to name them according to their usage in the application, e.g. form.label.login.username or cart.checkout or flashmessage.notice.

Using IDs also provides another layer of separation. Given that texting might not fall into the responsibility of either developer or template designer, it's better to have IDs in your templates.

Answer 2

To my opinion, it's wiser to think about setting great descriptive "keys" for your entries... Your "no_download" key doesn't describe the message well because it lacks a verb.

Keys, must be named after a good naming convention, as well as variables and functions.

Your key should be for example :

{{user_quota_exeeded}}

or

{{user_quota_exeeded_alert}}

In the long run, if your "real string" gets changed and the "dummy parameter" in the template doesn't, it will fool some of your co-workers/clients/...

Furthermore, it forces you to type your messages twice.

More on naming conventions on wikipedia.

Answer 3

Gettext does this already. It goes something like this:

_('Gettext does this already. It goes something like this:');

Answer 4

Those were all great answers, great insights, guys.

Arno, I am very aware of naming conventions. My example language key was indeed not very aptly named but it was only done so to serve as an example. Throughout the translation process of my web application, I came across strings that were hard to summarize/describe with a few strings, thus the thought of including the default language string as translation labels. I'm sure if you have worked on translation enough you will come across this scenario.

Anyway it is reassuring to see that Zend & Gettext have already adopted this approach.

Another question that popped into my head is the performance penalty.

Will using function calls , e.g. LANG() , take up significantly more resources than simply printing out $lang[] arrays?

What dya think?