[Resolved] language strings (ro, mo, it, etc.) being appended to menu items
looks like the dev may already be aware of this???
Twenty Thirteen 1.1
since the last WP upgrade to v3.7.1, and possibly 3.7.0 as well (or possibly haveing to do with the 1.1 theme upgrade?), there is a very strange issue with one nav menu on my site in which some – not all – menu items are being appended with strings like “,ro” “,it” “,mo”, etc..
obviously these are language strings and when i deactivate GLT, the strings are gone
you can test at 12bytes.org and you should see these strings only in the Software menu – all others are ok
sometimes it takes a few seconds for the strings to appear – seems to be dependent on the page being loaded
i haven’t noticed the strings being appended anywhere else, such as after text blocks as mentioned by another user
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.
Thanks for your post.
why is google being used to ‘translate’ content back to the default language? that seems strange – when de-translating, i would think everything should be coming from the db and google would be completely out of the loop
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!
thanks for the reply, but i still don’t understand why google is being used at all to “translate” the default language – this should come straight from the db, should it not?
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
i understand what you’re saying, but i still don’t understand why you are using google to translate the default lang? when the user translates back to the default language, this should come DIRECTLY from the db or wp cache or whatever, but not from google
it seems to me that GLT should be aware of what the default language is and then set the link for the button/flag/list item appropriately, where appropriately means pulling the text strings from the db and not google
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.
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 think you’re missing my point — the point is, GLT should have control over setting the strings back to the default language, NOT goole
from the statement i quoted, and from the appended strings which should not be appended, it seems clear that you are using google to translate back to the default lang.
you should be using the db/wp cache, NOT GOOGLE!!!
i’m marking this plugin as broken
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.
I’m closing this topic…..the solution has been provided to download version 2.6, which would solve this issue.
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.
it is absolutely expected that what the WP author wrote is precisely what is rendered on the visitor screen.
anything else constitutes a bug.
translating content back to the default lang, and using a 3rd party to do it, when that content is available in its original form in the db, is, as prometheangroup says, a waste of resources and one which can produce unwanted results
i would also wonder why flash is being utilized, even when the language is default
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.
Sorry about the typo… “Aron” is meant to be “Rob”… iPhone auto-correct strikes again!!!
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.
- The topic ‘[Resolved] language strings (ro, mo, it, etc.) being appended to menu items’ is closed to new replies.