I'm creating an Angular web app in English, but when I visit the site using Edge, it thinks my site is in Italian. I have absolutely no idea what would make it think that, and everything I find on the subject is geared towards Edge users changing their settings or translating pages. The end user shouldn't have to change any of their settings; they should never get a message that the site is in Italian in the first place.
How is Edge detecting language, and how can I configure my site so that it detects English? The only thing I know is having <html lang="en">, and I have that.
Normally you can specify the language via "lang" attribute. Since it doesn't work in this case, I suggest 3 possible workarounds:
Try making your <html> look like this: <html lang="en" dir="ltr" xml:lang="en">
Try adding this <meta> tag: <meta http-equiv="Content-Language" content="en">
If none of the workarounds above solves this issue, you can directly disable the translator prompt via this <meta> tag: <meta name="google" content="notranslate"> PS: Don't worry because users can still use the translation feature manually.
Related
I have, what I think, is a strange problem.
I have been creating a webpage for my site that, whenever I refresh the page, prompts Microsoft Edge (but not Chrome or FireFox) to ask me if I would like to translate the page from Portuguese and sometimes French.
I have been going through the HTML to identify what is causing this issue and I have discovered the following block of code is causing the issue:
<p class="ltol__pub">
This website is a publication of the livingtheOKlife company.
</p>
You may at this point be thinking that the name "livingtheOKlife" is causing the issue. However, I have used this name on multiple webpages in the past and never had this problem before. Furthermore, if I use a different line for the paragraph:
<p class="ltol__pub">
This website was designed and created by the livingtheOKlife
company.
</p>
The issue is resolved.
It is not an problem if I have to use the second line instead of the first. I can sleep at night if that is to be the case. However, I would very much like to know if anyone knows what may be causing the translate prompt to appear?
... and before you say it, I have included <html lang="en"> in the document.
... and I'm also aware this could be a bug, but I cannot find any record of it anywhere.
Add translate="no" in the <html> tag of your page. Also add <meta> tag with name="google" and content="notranslate" in the <head>. This tag should also work on Edge.
<html lang="en" translate="no">
<head>
<meta name="google" content="notranslate">
</head>
...
</html>
Facebook is not picking up open graph meta tags and the debugger responds as if they're not in the source code at all.
Here's the relevant page source (with title and url anonymized)
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Page Title</title>
<meta property="og:title" content="Page Title" />
<meta property="og:url" content="http://page.url/page-name" />
<meta property="og:type" content="article" />
I found the problem. For posterity: Grav CMS sends a Content-Encoding: none header when GZIP is not enabled. Facebook doesn't like this header, it breaks it's libcurl. In the sharing debugger it doesn't report this, it instead says the tags are missing.
The simplest solution of course is to turn on GZIP in Grav config.
Side note: I thought Grav was going to be a quick solution for a family member, the simple interface coupled with it supposedly being developer friendly under the hood appealed to me. Turns out it's developer friendly in the sense that you will encounter problems that will require your developer experience to solve as a result of there being numerous documentation errors, missing basic features and bugs in the plugins required for basic functionality. Also note that Google is not your friend for solving Grav problems as there's surprisingly little community support compared to other popular CMS.
Not saying this to trash Grav, there's a lot about it that's good, the above is just stuff I wish I'd known going in.
The Social Meta Link plugin readme now explains the gzip issue, but for me I additionally had to patch the plugin source code by hand on the server to strip the internal port number from the og:url meta links because I run a reverse proxy setup.
Below meta tag syntax is accepted by the browser,
<meta http-equiv="refresh" content="3; redirect.html"/>
but, https://validator.w3.org could accept below syntax(only),
<meta http-equiv="refresh" content="3; url=redirect.html"/>
So,
1) Why browser accepts lose syntax of html?
2) For production code, what is the standard approach to validate html syntax?
There were bugs (or simply loose parsers) in browsers.
People wrote code that depended on those bugs.
Other browsers copied those bugs so that the code from the previous step would work.
Go to 1.
The new Google Chrome auto-translation feature is tripping up on one page within one of our applications. Whenever we navigate to this particular page, Chrome tells us the page is in Danish and offers to translate. The page is in English, just like every other page in our app. This particular page is an internal testing page that has a few dozen form fields with English labels. I have no idea why Chrome thinks this page is Danish.
Does anyone have insights into how this language detection feature works and how I can determine what is causing Chrome to think the page is in Danish?
Update: according to Google
We don’t use any code-level language information such as lang
attributes.
They recommend you make it obvious what your site's language is.
Use the following which seems to help although Content-Language is deprecated and Google says they ignore lang
<html lang="en" xml:lang="en" xmlns= "http://www.w3.org/1999/xhtml">
<meta charset="UTF-8">
<meta name="google" content="notranslate">
<meta http-equiv="Content-Language" content="en">
If that doesn't work, you can always place a bunch of text (your "About" page for instance) in a hidden div. That might help with SEO as well.
EDIT (and more info)
The OP is asking about Chrome, so Google's recommendation is posted above. There are generally three ways to accomplish this for other browsers:
W3C recommendation: Use the lang and/or xml:lang attributes in the html tag:
<html lang="en" xml:lang="en" xmlns= "http://www.w3.org/1999/xhtml">
UPDATE: previously a Google recommendation now deprecated spec although it may still help with Chrome. : meta http-equiv (as described above):
<meta http-equiv="Content-Language" content="en">
Use HTTP headers (not recommended based on cross-browser recognition tests):
HTTP/1.1 200 OK
Date: Wed, 05 Nov 2003 10:46:04 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
Exit Chrome completely and restart it to ensure the change is detected. Chrome doesn't always pick up the new meta tag on tab refresh.
I added lang="en" to the doctype declaration, added meta tags for charset utf-8 and Content-Langauge in the HTML header, specified charset as utf-8 and Content-Language as en in the HTTP response headers and it did nothing to stop Chrome from declaring my page was in Portuguese. The only thing that fixed the problem was adding this to the HTML header:
<meta name="google" content="notranslate">
But now I've prevented users from translating my page that is clearly in English to their own language. Poor job, Chrome. You can be better than this.
Specify the default language for the document, then use the translate attribute and Google's notranslate class per element/container, as in:
<html lang="en">
...
<span>English</span>
Explanation:
The accepted answer presents a blanket solution, but does not address how to specify the language per element, which can fix the bug and ensure your page remains translatable.
Why is this better? This will cooperate with Google's internationalization versus shut it off. Referring back to the OP:
Why does Chrome incorrectly determine page is in a different language and offer to translate?
Answer: Google is trying to help you with internationalization, but we need to understand why this is failing. Building off of NinjaCat's answer, we assume that Google reads and predicts the language of your website using an N-gram algorithm -- so, we can't say exactly why Google wants to translate your page; we can only assume that:
There are words on your page that belong to a different language.
Marking the containing element as translate="no" and lang="en" (or removing these words) will help Google to correctly predict the language of your page.
Unfortunately, most people reaching this post won't know what words are causing the trouble. Use Chrome's built-in "Translate to English" feature (in the Right-Click context menu) to see what gets translated, you may see unexpected translations like the following:
So, update your html with the appropriate translation tags until the Google Translation of your page changes nothing -- then we should expect the popup to go away for future visitors.
Won't it be a lot of work to add all these extra tags? Yes, very likely. If you are using Wordpress or another Content Management System then look in their documentation for quick ways to update your code!
Without knowing what the text was, perhaps the ngram detection is being tricked by the content of your page.
http://googleresearch.blogspot.com/2006/08/all-our-n-gram-are-belong-to-you.html
https://en.wikipedia.org/wiki/N-gram
Chromium thinks this page in Filipino: http://www.reyalvarado.com/portfolio/cuba/
Notes: There is pretty much no text on the page except for the owner's name and the menu items. Menu items are dynamically replaced with images by FLIR.
The HTML declares the page as US English:
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">
Try including the property xml:lang="" to the <html>, if the other solutions don't work:
<html class="no-js" lang="pt-BR" dir="ltr" xml:lang="pt-BR">
I have a page using something along the lines of
<meta http-equiv="refresh" content="0;url=http://example.com/" />
but for certain users on a certain workstation this doesn't work. The is in IE. Is there something wrong with cookies or a setting somewhere which would cause this to fail? I never heard of such a thing.
The problem is that when IE sees this:
<meta http-equiv="refresh" content="0;http://www.example.com" />
it expects the contents attribute to contain a number. The only time IE will check for a URL is if the content attribute contains "URL=" so the redirect that is most usable in all browsers is this:
<meta http-equiv="refresh" content="0;URL=http://www.example.com" />
The above example would redirect immdetiately but if you changed the 0 for another number it would wait that many seconds. Hope this all makes sense, it should work just fine but I still think my first idea was the better one.
There is a security setting in internet explorer that does not allow meta tag refresh. It is under the Security tab, then choose Custom Level and the Meta Tag Refresh under Miscellaneous. If that is disabled, it would stop the meta refresh from working.
Aside from being able to disable it selectively, it is automatically disabled if you set IE's security level to 'High' [observed in IE9].
is it a really old version of IE? if so, try:
<meta http-equiv="refresh" content="0;url=http://example.com/"> </meta>
It needs a white space. HTML editor will complain, but just ignore it.
Check out this solution. It handles both javascript and meta-refresh at the same time:
Meta-refresh and javascript
The META tag is not an empty tag and does not have a closing tag in HTML, only in XHTML. (If you are really are sending XHTML, it may not work right on older versions of IE anyway, there are only workarounds to send XHTML to older IE versions.)
Try:
<meta http-equiv="refresh" content="0;url=http://example.com/">
W3 Schools META Tag Description
You might also try:
Checking the major and minor versions of IE. You can do this on the help->about menu option.
IE has historically gotten all confused by filenames and MIMEtypes. Make sure that you are sending your HTML as an htm or html extension file, and that those filetypes are set up on your server to send text/html mimetype.
Make sure your server isn't sending a conflicting meta refresh http header.
In case anyone tries to use meta refresh to redirect to new URL in Facebook applications ( either Page Tab app or IFRAME app ), the tag is disabled by Facebook somehow.
Workaround is:
<script>
top.window.location = 'http://example.com';
</script>
Remember to target "top", as Facebook applications are in IFRAME.
Just a wild guess: maybe there are some adblockers installed on those machines where the redirect does not work.
Can't think of any other reason why this common technique works on some machines while it fails on others for you.