installed RW8 and had a wonderful and (almost) seamless experience upgrading all my project to the new version (files in resources had disappeared in the Split-Themen. Easy fix).
The new Site Language option is very intriguing. However, I have a project that has a couple of sites in different languages and/or same languages but related to different countries:
I cannot set the site language as it would override reality on the various blog pages.
I’m using the extended attributes that both indicate language AND country: de-de for German in Germany, en_us for English in USA, en_uk for English in UK etc.
Since Google hates duplicate content, I’ve only opened up the German the US page for robots. However, time will come where I fill different content into the various blogs.
Any idea how to script that? I could fiddle in the code but I’d have to do it over and over again with each upload of modifications.
I am very excited by the fact that RW entered the multi-lingual realm.
However, as I mentioned in another post, there are websites that use things like RWML stack from S4S or Localizer from inStacks. That means that each page in a project comprises of a content in all languages (as opposed to sites where there are separate pages for each language).
I think it would be worth investigating possible inclusion of features for both single-language-per-page and single-page-for-all-languages.
@Rovertek Hi Rob, I think this is going to be down to each plugin to generate the correct HTML here. For example, a plugin could specify:
<p lang="fr">Oui</p>
<p lang="de">Ja</p>
RapidWeaver has no control over this - it asks a plugin (such as Stacks, who might then ask the RWML stack for its content). All RapidWeaver can change is what’s around the plugin content.
So: we could potentially allow plugins to override the page language (either so it’s not set, or it’s set to something else) and let them decide - but it’s not something you’ll get automatically unless the plugin developers and the stack developers put in the work too.
The problem with HTML lang="" attributes is that you get that ugly flash-of-all-content before the client side Javascript kicks-in and decides what block of content to display. It can make page loading much slower and more jumpy.
This method can be made to work with RWML, but it’s neither a pretty or efficient way to handle multiple languages. Strictly speaking, it is not really what HTML lang attributes were designed to do. This is how RWML v1 used to handle multiple languages, and is something we have been trying to move away from in RWML v2.
The better method would be to use server side PHP code, like the RWML Wrapper stack does:
<?php if(isset($rwml)) { if($rwml->isActiveLanguage("de")) : ?>
<!-- Put your German content here -->
<?php endif; } ?>
In this example, the content between the two PHP tags only gets sent down to the web browser if the user has selected German (de) as their active language. Although the code is more cryptic to look at (you’d struggle to type it after a few beers), the clear advantage here of doing the conditional display of content server-side is the enormous performance boost gained.
Feel free to save that as a code snippet and reuse it anywhere in your website, where the RWML Wrapper stack can’t be placed.
You’re absolutely right. I just thought that limiting multi-lingual capabilities of RW to single-language-per-page is a bit… limiting (although it’s a good starting point).
I’m sure, in the future there will be some more efforts to make RW a fully multi-lingual tool—when YourHead in tandem with developers of individual stacks will work out the ultimate solution.
From where I stand, the multi-lingual capabilities seem to be way too important to be neglected or overlooked by all but a couple of developers involved with RapidWeaver application and/or its add-ons.
we could potentially allow plugins to override the page language (either so it’s not set, or it’s set to something else)
I think that must come from whichever theme you’re using - I can’t find anywhere in the RapidWeaver codebase where we’re adding this. Try with another theme - if it disappears, you’ll want to get in touch with the theme developer. It’s also possible that it comes from whichever plugin you’re using.
I didn’t realise that was what was being referred to here - I’d assumed there would be multiple languages displayed on a page. In that case, yes, doing it server side based on the Accept-Language header (or similar) would be most appropriate.
I guess there is some confusion on who generates this code, the Theme developer or RapidWeaver. Even the sample Theme in the Theme development Kit on GitHub, and all the new RW8 themes have the <meta charset="utf-8"> in the Theme.
The code that Rapidweaver generates is the older HTML4 (1997) <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> so at the least RapidWeaver should generate the newer style. They need to update the Their developer NOT to include this in their themes and update the developer kit. I don’t think an end user has to have to contact the developers of each theme when the sample theme in RealMacs Developer kit is incorrect.
The HTML 5 way of doing HTML Encoding (Character Sets) is that some Theme develops are adding:
<meta charset="utf-8">
What Rapidweaver Generates is the old HTML 4 equivalent:
The element with a charset attribute is a synonym for the pre-HTML5 , where IANAcharset contains the value of the equivalent charset attribute. This syntax is still allowed, although no longer recommended.
The W3C specs also state it’s alright to user ether but not both.
Themes I Have Found That Contain the Duplicate Charset declarations:
Hi @dan!
Thanks so much for implementing the language override per page.
As I’m German, there’s a “however”…
Google hates duplicate content. However, if you do a multilingual project for (as I do) Germany, USA, UK, Australia, South Africa, France, Spain, Italy, Netherlands and Japan, you run into the following problems:
I have English texts that sometimes need to show up on the US, UK, AUS and RSA-pages. Since I can only chose “English” not en-us, en-gb, en-au and en-za, Google assumes that is all dupliate content as there is no distinction between the page with just the short “en” attribute. Since the pages have a blog which is country specific, I cannot simply reuse one blog instance on all en pages. Same is going to be valid for spanish (Spain, middle/latin-America, portuges (Portugal, Brazil), French (France, parts of Africa), German (Germany, Austria, parts of Switzerland) and so on. If you were just expanding to the extended attribue (language AND country), that would fix the problem…
Any chance?
Thanks a lot for considering! This would help RapidWeaver to cross oceans!
If Google and duplicate content is the concern, then the Lang attribute on the HTML tag probably isn’t going to solve this for you. Per Google, they only look at one of three methods to determine localized versions of a page
HTML Tag (head section)
HTTP Header
Sitemap
The easiest one would be to add an HTML tag to the head section:
Thanks a lot for your kind help. Two things that I found out:
If I put the code in the Head-section, it only appears way down in the sourcecode of the page. This is what Google suggested not to do. Shall I rather put it in the prefix-section? Then, it appears before the !DOCTYPE tag.
It looks like that now:
initial page (just a one time splash:
You definitely want any rel link tags, like this or canonical URL in the head section. Google should read the entire head section without any issues assuming you don’t have any syntax errors that would cause bots to think the head section was closed.
Put your <link> tags near the top of the <head> element. At minimum, the <link> tags must be inside a well-formed <head> section, or before any items that might cause the <head> to be closed prematurely, such as <p> or a tracking pixel. If in doubt, paste code from your rendered page into an HTML validator to ensure that the links are inside the <head> element.
This would tell me that as long as it’s inside the head you’re okay. I’m no expert on this just reading the guidelines I linked to above.
I believe you need a set of these on each page.
Each variation of the page should include a set of <link> elements in the <head> element, one link for each page variant including itself .
