Translator help

Hi.

Trying to make a simple translator for templates, where little snippets can be passed through, and it returns the translated string.

I’m running into one problem. In the code sample below, on my second call to

{exp:xlate t=“Login”}

I get the results of {exp:xlate t=“Username”} instead.
Logging calls inside my plugin, its as if {exp:xlate t=“Login”} is never called the second time.
However, if I make it {exp:xlate t=“Login2”} then it gets called properly.

Hoping someone can help clear up for me what’s happening here.

Code for plugin: http://pastebin.com/f35bb385

snip from template:

Thanks,
m.

Moved by Moderator to Plugins: Technical Assistance

Hi, plank.

Moved this post to the Plugins area since it’s beyond the scope of Technical Support.

thanks sue

changing the second call to have an extra param that the first one doesn’t

ie

{exp:xlate t=“Login” r=“foo’} makes it return the right result, so I’m guessing this has something to do with how EE caches the results of a call to a plug in. So the question is, why does it pull the wrong results. Is it something i’m doing in my plug in?

I’m a bad searcher. This issue is a dupe of

http://expressionengine.com/forums/viewthread/81127/

where the person encouters the same problem. Still open to know why its happening if anyone has any ideas.

Due to the way EE processes plugin tags, as alluded to in the other thread, {exp:xlate t=“Login”} wouldn’t be called the second time, but I would expect it to be replaced with the results of the first call to that, not the results of {exp:xlate t=“Username”}.  Unfortunately, the link to your plugin code is not working for me so I can’t say anything further at the moment.

hey jesse,

the link
http://pastebin.com/f35bb385

seems to be loading fine for me.

are you stlll not able to see it?

m.

Ok.  It’s not a problem with your plugin, it’s a problem with EE’s template parsing.

What’s happening is that your template is being parsed in two passes.  On the first pass, all of your tags that aren’t nested within {exp:member:login_form} are parsed and replaced with a gibberish string:

The only difference between those gibberish strings is the second character, which is an integer that increments for each tag / pair that’s processed.  Each parsing pass does the same thing, starting the counter at 0.

Meanwhile, the contents of {exp:member:login_form} are stored in a variable.  When the first reference to {exp:xlate t=“Login”} was replaced with the gibberish string M00o93H7pQ09L8X1t49cHY01Z5j4TT91fGfr, the second one, inside {exp:member:login_form}, also was.  So the variable that holds the contents of {exp:member:login_form} contains the gibberish string, not the tag code {exp:xlate t=“Login”}.

After the first pass, each of the 3 gibberish strings listed above has been replaced with the appropriate value.  However, {exp:member:login_form} still contains unparsed tags and the gibberish string in place of {exp:xlate t=“Login”}.

On the second pass (for the contents of {exp:member:login_form}), all of your tags that are nested within {exp:member:login_form} are parsed and replaced with a gibberish string:

Notice that EE has done the same thing as the first pass—created gibberish strings that differ only by the integer that is the second character, which again started at 0.  The result is that the gibberish strings produced in this pass are the same as those produced in the first pass.

At the beginning of this pass, the contents of {exp:member:login_form} contained the gibberish string M00o93H7pQ09L8X1t49cHY01Z5j4TT91fGfr in place of the reference to {exp:xlate t=“Login”}.  Now, during this second pass, EE has replaced the reference to {exp:xlate t=“Username”} with that same gibberish string.  Then when EE replaces the gibberish strings with their values (which it does in the order the tags were encountered in source order—so starting with {exp:xlate t=“Username”}), it replaces all instances of the gibberish string M00o93H7pQ09L8X1t49cHY01Z5j4TT91fGfr with the value produced by {exp:xlate t=“Username”}.

Unless and until EE’s template parsing is improved, the solution here is the same as in the other thread: add a gibberish string of your own in an otherwise-useless parameter to your tag, e.g. first: {exp:xlate t=“Login” rand=“abc”}, second: {exp:xlate t=“Login” rand=“xyz”}.

I don’t completely understand how your plugin is supposed to work.  Alternatively, perhaps it would be possible to restructure your plugin / template to work in this fashion:

Thanks jesse. That helps clear it up, and for now, will use the gibberish param as a fix, since its only in one or two locations for this project.

re: I don’t completely understand how your plugin is supposed to work.  Alternatively, perhaps it would be possible to restructure your plugin / template to work in this fashion:

Its just meant to be an easy way for the templaters to pass small bits that need translating (multiling site), and have it spit out the input string if the translation not found.

Also meant to be able to call $helper->in(‘foo’) when i need it when doing some template php work.

thanks for the explanation.

Its just meant to be an easy way for the templaters to pass small bits that need translating (multiling site), and have it spit out the input string if the translation not found.

Right.  It just seems awkward to me to use such long, complicated strings as lookup keys.  If you ever want to edit any of that text—even by one character—wouldn’t you then have to update every language file?

Jesse McCarthy - 27 June 2008 12:13 PM

Right.  It just seems awkward to me to use such long, complicated strings as lookup keys.  If you ever want to edit any of that text—even by one character—wouldn’t you then have to update every language file?

yes.
I’m pushing them to use keys, but while they work sometimes they will use full strings, especially during the initial templating process.

Perhaps you could use a compromise approach, like one of the following: