I run a website that is in English but iOS 14 mobile Safari still offers to translate the page. How do I prevent this?
From this similar question I've found none of these work:
1. <html lang="en">
2. <html translate="no">
3. <meta name="google" content="notranslate">
4. <meta http-equiv="content-language" content="en" />
Isolate the offending bit(s) that are triggering the translate offer. Start with a skeleton:
<!DOCTYPE html>
<html>
<head><title></title></head>
<body></body>
</html>
Did that trigger a translate offer? If not, great, start adding some of the code from the problem page to your skeleton, reloading as you go, until you find the offending bit(s). Once you find out what's triggering the translate offer, you might be able to modify your code or content so that doesn't happen.
I submitted this issue to Apple and it was fixed with iOS and macOS releases in December 2021.
A WebKit engineer via Twitter exchange suggested I submit the specific instance of my issue with the URL in question to Apple using Feedback Assistant. I did this and was then asked to test with builds 19D5026g (iOS) and 21D5025f (macOS). These fixed the issue.
Solution
You can try html tag like this
<html translate="no">.
This will make your html page to non-translate.
Other Versions
<meta name="google" content="notranslate">
<html lang="en" class="notranslate">
<meta http-equiv="content-language" content="en" />
For more: https://www.w3.org/International/questions/qa-http-and-lang
Related
this is my first post, and I'm currently having some difficulty with the custom HTML templates within DecoNetwork, would really appreciate some advice, please!
The DecoNetwork e-commerce sites are predominantly built using a drag and drop editor, but there are also custom HTML and custom CSS templates where you can override settings with your own code.
DecoNetwork seems to also use Liquid (according to their support pages), but I'm not sure if this is what is used in the <[{"snippet":}]> code below as it doesn't seem to follow the usual process of Liquid? As well as this, are these snippets of code locked down, or are they able to be manipulated?
<!DOCTYPE html>
<html class="wf-loading">
<head>
<[{"snippet":"system_style_sheets"}]>
<[{"snippet":"system_head_js"}]>
<title><[{"snippet":"title"}]></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0"/>
<[{"snippet":"system_head_meta_tags"}]>
<[{"snippet":"favicon"}]>
</head>
<body class="dn-site">
<header>
If anyone can point me in the right direction of whether I've got the right language here that will help with getting my head around this platform.
Many thanks
I'm having issues with sharing a website I'm working on on LinkedIn: LinkedIn doesn't fetch any data from the page. The site's metadata follows the recommendations in their docs. I tried all these suggestions.
In addition, I investigated the following:
Serving content over HTTP instead of HTTPS, but a lot of other sites served over HTTPS, such as https://stripe.com/no and https://www.facebook.com/, work perfectly fine.
Posting as a company page. This didn't make any difference, other than allowing manual data entry (which is handy as a makeshift solution).
Posting as a different user. Didn't make any difference.
Posting new content on the website to make sure that the metadata hadn't been cached by LinkedIn. This also didn't make any difference.
This was also a problem before I added the Open Graph meta tags.
This might be a problem caused by LinkedIn, but – considering that this works for other sites – I'm open to the possibility that I'm the one doing something wrong.
I don't think you will see any changes in the data that LinkedIn grabs from your website for about a week:
The first time that LinkedIn's crawlers visit a webpage when asked to share content via a URL, the data it finds (Open Graph values or our own analysis) will be cached for a period of approximately 7 days.
This means that if you subsequently change the article's description, upload a new image, fix a typo in the title, etc., you will not see the change represented during any subsequent attempts to share the page until the cache has expired and the crawler is forced to revisit the page to retrieve fresh content.
https://developer.linkedin.com/docs/share-on-linkedin (scroll to the bottom)
In my case it seemed that LinkedIn Parser is really poor to the point that if your HTML file doesn't have the <head> tag (which is not required by the spec) It will simply ignore everything where the bellow wouldn't work
<!doctype html>
<meta charset=utf-8>
<meta property=og:title content='My Shared Article Title'>
<meta property=og:description content='Description of shared article'>
<meta property=og:image content=http://i.imgur.com/12345.jpg>
<meta name=description content='Nice description'>
<title>TEST 15</title>
<p>content here</p>
But simply adding the opening <head> tag (still valid HTML), did the trick
<!doctype html>
<head>
<meta charset=utf-8>
<meta property=og:title content='My Shared Article Title'>
<meta property=og:description content='Description of shared article'>
<meta property=og:image content=http://i.imgur.com/12345.jpg>
<meta name=description content='Nice description'>
<title>TEST 15</title>
<p>content here</p>
I was having the exact same issue. Clear your cache history. Then add this 'prefix="og: http://ogp.me/ns#'" to each metadata tag, and it will work immediately:
<meta prefix="og: http://ogp.me/ns#" property='og:title' content='Content Title'/>
<meta prefix="og: http://ogp.me/ns#" property='og:image' content='https://images.url...'/>
<meta prefix="og: http://ogp.me/ns#" property='og:description' content='Description'/>
<meta prefix="og: http://ogp.me/ns#" property='og:url' content='https://site_url/'/>
This will fix it for you just enter your website into here and it seems to clear their cache which in my case was about 3 years old cache ???
https://www.linkedin.com/post-inspector/inspect/
As in all things programming, let's first look at the Official LinkedIn Sharing Documentation! The LinkedIn share API will respect the following og: tags in your HTML...
<meta property='og:title' content='Title of the article"/>
<meta property='og:image' content='//media.example.com/ 1234567.jpg"/>
<meta property='og:description' content='Description that will show in the preview"/>
<meta property='og:url' content='//www.example.com/URL of the article" />
Want to be sure you're using it right? That's easy -- check out the Official LinkedIn Post Inspector to have your share URL debugged, checked, and verified.
How do I enable the icon which is shown in chrome´s address bar next to the favorite star?
The site will be in greek but for now I need this icon to appear to make one click translations for non greek speakers.
I added:
<html lang="el">
<meta charset="UTF-8" />
<meta name="google" content="translate" />
<meta http-equiv="Content-Language" content="el-GR" />
But nothing..
Basically seems like the opposite to this article
Disable Chrome translation bar on my website.
Thanks
I'm fairly sure that chrome automatically does this by seeing what your language preference is and then comparing it to the language displayed on the page. No additional code is required.
In a search towards minimalistic webcoding practices I saw this on the top of my webpages:
<!doctype html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="language" content="nl"/>
A: when should one keep the second line (xmlns) and when can it be removed?
B: my website is multilingual so pages come in variety of languages. I kept the xmlns since I swa you can put in lang= and xml:lang= so thought that might be handy, but I don't use xml I think... just php generated contents etc. UPDATE I just got advise to use <html lang="de"> which will suffice for me. True?
C: when does one need the third line http-equiv? When can it be removed entirely?
D: do browsers recognize/process the fourth line or do they skip it nowadays?
Thanks very much!
If you haven't already, read up on HTML5 here or maybe here, and maybe even here. HTML5 is the latest HTML spec currently under development by the W3C, and is pretty much awesome.
For your questions:
Q1: See this SO question. Basically, you won't need the xmlns or xml:lang attribute.
Q2: Yes, see below.
Q3: You don't need to specify content-type anymore, however you should always specify the encoding (see below). In reality, though, you can use either one, so I would just stick with the short version. See this SO question for more info.
Q4: That's a difficult question to answer because it really depends on the browser / version. However, it's a moot point since the lang attribute should really be moved into the html tag (again, see below).
Below is what I consider the bare minimum a proper web page should include, (sans the comments):
<!DOCTYPE html>
<html lang="en"> <!-- use whatever language code is appropriate here -->
<head>
<meta charset="utf-8"> <!-- utf-8 is universally the best encoding option -->
<title>My Cool Website</title>
</head>
<body>
</body>
</html>
Is
<base href="http://google.com" />
<img src="/intl/en_ALL/images/logo.gif" />
supported in chrome? It works fine in firefox.
Specifically, relative image links aren't resolving to the base url.
It is for:
http://webnumbr.com/create?url=http://google.com
Tested in latest of OSX and Windows Chrome (4.0.249.78)
And to answer your question about the <base> tag being supported in Chrome: it is. I created a simple HTML document:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=UTF-8">
<base href="http://google.com">
<title>Testing base-tag</title>
</head>
<body>
<img src="/intl/en_ALL/images/logo.gif">
</body>
</html>
which is rendered correctly.
EDIT: PROBLEM PROBABLY DISCOVERED
I searched the Chromium bugs page for "base tag" and found two (probably the same) bugs about your problem, i.e. issue 25090 and 32134.
I suggest you file a comment in one of those (after deleting the forbidden end tag of <base>) and hope this problem is resolved soon.
EDIT 2: I made another test case and commented in this bug report.
EDIT 3: Bug seems to be resolved after upgrading to Chrome 4.0.249.89.