Feature to make multilanguage coding easier

[GoogleCodeExporter]

I would like a passthrough i18N function.

This is how it would work.

Instead of having to create en tokens for all literals we are using in our 
code, and new code. We can simply use a passthrough in code, then add the 
tokens later on for translations. This also prevents having to go back into 
code to convert string literals into i18N lookups or predetermine them during 
the dev process.

So instead of coding away and having to deal with 'oh this should be 
internationalized', or going back later on and trying to find them.
how is it now
eg. i18n('STRING_TOKEN')

I propose a function that does this.
* yes i know there is a echo parameter, which I hate, lets pretend there isnt 
for now.
A optional argument to pass in the default string if token doesn't exist.

i18n('STRING_TOKEN','This is my en string that goes here')

Then if the index doesnt exist, it just returns the second string.
* if the index does exist and we are providing string, in a dev environmental 
we can throw an painless conflict exception to prevent dups.

Also 
Later on we can do a live log of this function and dump it directly in to a 
translation file, or do a simple code search with some clever processor to 
parse the args.

so advantages
1. not having to deal with translations at dev time.
2. instant placeholders in code for later reference.
3. automatic file generation and maintenance is possible.

Original issue reported on code.google.com by tablatronics on 19 Apr 2012 at 9:33

[GoogleCodeExporter]

Original comment by tablatronics on 19 Apr 2012 at 9:36

• Changed state: Debate

[GoogleCodeExporter]

this sounds like a great idea. 

Realizing now that I should do all my translations as I'm writing as its 
becoming a bit of a pain now going back through my code to find all the string 
and set it up. 

This is a much better way of doing things. 

Original comment by MichaelS...@gmail.com on 20 Apr 2012 at 11:15

[GoogleCodeExporter]

i like this as well - (where were you 2 years ago when we were looking for a 
solution?? haha) - but i am concerned with backwards compatibility.

Also - how would a translator get all the strings that need parsed? I assume 
that is where your "auto file generation" comes into play.

Original comment by ccagle8 on 14 Jun 2012 at 12:59

[GoogleCodeExporter]

I suggest we deprecate i18n() function.
We continue support for it by leaving it in obviously.

We create 2 new functions.

function get_i18n(token,defaultstr){ ... }

function return_i18n(token,defaultstr){ echo get_118n(token,defaultstr) }

benefits, no more echo flag arguments, no mysterious function name.
And inline default transliteration strings until lang files are created.
We can go back and edit them out, or leave them in, whatever.

To find them, we can create a script to parse the codebase for all matching 
functions and extract tokens and strings to convert into lang files. or we 
could dynamically add them as they are called using some kind of unitests.

Of course we could also add this support to i18n() by detecting if the second 
argument is bool or a string. But that is just confusing.

Original comment by tablatronics on 20 Jun 2012 at 2:01

[GoogleCodeExporter]

actually I wasn't thinking, we already have 
i18n_r($name)

It's trivial to add a second parameter to it.

Original comment by tablatronics on 24 Jul 2012 at 2:13