language strings (ro, mo, it, etc.) being appended to menu items

Hi atomizer, your link above is not working.

And yes, there was a small attribute change in version 2.7 that is causing conflicts on some sites, although it should not do that. I added the “multilanguagePage:true” attribute to the plugin, which is supposed to apply all language on a page to a strict single language (whatever is chosen by user at the time.)

But the main issue we found is that Google is failing to translate the website back to it’s original language, even when installed directly from their website, even with our plugin de-activated. Instead, Google switches to a hard translation of a single language, instead of switching back to the original, which somehow doesn’t work.

Our free plugin can get around this problem when using the flags, athough the drop-down box is showing issues and a fix is needed, which we are able to do for users by using custom functions that bypass the standard translation function in our free version.

We have fixed a few sites by having our users purchase the premium version of our plugin, so that it works smoothly like users want. I personally do not like having to ask users to purchase the plugin just to fix an issue, but it’s the solution at this point, nonetheless.

Here’s a website where we added the premium version, and it seems to work great, even when using the “multilanguage:true” attribute mentioned above.

http://www.controsys.com/

Another issue is that some sites have heavy javascript, which is conflicting with Google translate ability. Either way, we are bypassing this issues with our custom functions that access Google translation differently, which seems to handle much better.

Thanks for your post.

Hi atomizer, I have new information on this issue, which just recently became available after some testing.

I appears that Google will append these characters on the end of words, when the word is something other than your default language. So this present problems for users who, for example, have a German-based website but provide words in English to their web visitors.

For example, on a German website, the word “Facebook” is commonly accepted as English language, so Google will append “,en” on the end of it, but ONLY when switching back to the default language.

The solution is this: 1) Provide words only in your original language, or 2) add class="notranslate" to the specific areas that have those words on your website. That should fix a majority of your issues.

My previous suggestions do solve the problem too, but as I suspected, this is really a more simple issue with how Google reads words. Let me know if you have any success with those solutions.

Also, please revert back to version 2.6 when trying this – that version does not use “multilanguagePage:true” option with Google, which will likely solve 100% of your issues, combined with solutions #1 or #2 above.

Let me know how it goes!

Hi atomizer, yes your web content is pulled from the database for sure, but then Google takes that information, translates it through their servers, and then translates back to the default language of your website (still controlled at that point by their servers).

But when they translate back to your original language, I am seeing that they use a slightly modified version of your default language.

So, for example, if you have a sentence that reads, “Jack has built a highly specialized network of services” in English (as the default language before translation), then Google may translate that same sentence to this: “Jack has built a network of highly specialized services”. The translation is based on machine translation, but it’s guided by human users who have provided translation suggestions from all around the world. There is actually a component of Google translate that allows you to manage translations of your own website, which I plan to allow access to in the next phase of this plugin. Stay tuned for that.

So to answer your question, “English” (as Google understands it) might be slightly different from the default language of your webpage, and Google controls it all after you translate initially from another language.

I hope that helps explain this better

atomizer, I agree 100% on this, and in some cases this actually might be the case, where Google does not translate to their version of default language, but instead they translate to your original language. I should have not spoken so fast.

On some websites, I do notice that translations go back to the actual default langauge, and not the hard-coded language as I mention above. But with so many complications in different locations around the world my head is spinning! So I’m sorry to mis-lead you on my statements.

Actually you will notice that once you translate to a foreign language, then come back to your original language, Google will reset the drop-down box with “Select a language”, and not English, which would suggest it’s the 100% true default language, and not coming from their servers. I believe you are right about this point.

Rather, I should have said that I have seen instances where clicking on “English” would produce a Google version of English, and not the default language, but I think this is when using the multi-language option, which purposely hard-codes English to their version.

And for this exact reason, that is why I’m pushing users to revert back to version 2.6, because it will allow websites to revert back to actual default language, and not the hard-code version. In addition, I’m finding out that this multi-language option has caused some problems on Google’s side, so I’m going to avoid that option as default in my next update.

atomizer, I do understand your point now, although the plugin does this properly in my version 2.6. Please try this. In the case of that version, I would not need to insert my own call to your database in order to do this.

Yes, I could in theory, stick my own custom function in the middle of Google’s code, and then call back to your original webpage, but Google is supposed to do this anyway. My #1 goal is to stick with the way their tool is suppose to work, which it does, in version 2.6.

FYI for the community… Although we always appreciate highly responsive and active plugin authors, such as Rob… This topic is definitely not resolved. A couple of fundamental problems with the plugin are that if the user wants the respective site in the default language, processing the GLT code is tremendous overhead and latency when no processing is needed. And second, it just a matter of semantics, but IMHO, most developers would consider the concept of “re-translating” the default language a major bug in the plugin. I understand Rob’s point that the “default language” could potentially be a slightly different concept than the native language in the WordPress database content, but that is such a stupendously microscopic case, it’s simply poor logic. I see both points, but in the end, I would vote to design the plugin for maximum usability with the vast majority of installations, instead of fiercely sticking to a philosophical point, which could be valid… SUMMARY: Please simply provide a checkbox option to DISABLE GLT if the default language is chosen.

Okay… I’ve done some more digging into how Rob designed the plugin… And now I see why he’s having trouble fixing this bug… First if all, it is definitely a bug… But it is not Aron’s bug… It is a Google bug… It appears that for the free. Version, Rob is pulling code from Google to not only render the selector drop down, but also to fire off functions… So Rob may simply not have access to modify those functions… Which is probably why he takes full control of the plugin code in the paid version… I have tested both the free and paid versions… The free version 2.7 does exhibit the bug, and should be pulled down, IMHO… The 2.8 paid version seems to be working fine, and for $12 probably won’t break the bank… In summary, the paid version is a great plugin… Great job, Rob… The free version, not so much.

Hi prometheangroup, awesome contribution. Thanks!

And here’s what I have found since my last post here. The drop down in the free version will actually work correctly on some sites, and not others. I’m finding that sometimes, Google’s drop-down will revert nicely back to the original language, and then other times, the plugin goes to “hard” English. Maybe this is a server thing, not jiving with Google?

And version 2.7 free actually does work correctly on most sites, although with those few problem cases, the work-around has been to scrape text to make sure that Google “understands” it. By scraping, I’m talking about acronyms, abbreviations, and other text with unique characters need to be evaluated. When I have made those adjustments, all of the other translation errors disappear from the website.

When Google understands it, I’m finding that websites will work great.

But for users this should not be such a chore, so I will continue to provide support in those cases where problems arise. Usually it’s only a couple of problem words, or the site title throwing things off, which has not really been tedious up to this point.

Thanks prometheangroup!

Rob