Jump to content

Language names and UTF8 page names


adrian
 Share

Recommended Posts

Another noob question in my ML journey :)

Should I name additional languages using the English version of their name, or the native language version of its name, eg:

German vs Deutsch?

Portuguese vs Português ? @diogo - since this is the first non-English language I have to set up, I'd love your opinion here please.

Also, what is everyone's thoughts on UTF8 page names / urls? Should I enable, or stick with the old system of replacements?

Thanks again for the help!

Link to comment
Share on other sites

I name them at their original language but usually they are readable (latin). When it comes to cyrillic or chinese characters I would probably use English. But it depends on who will use the admin, and whether to use these names (titles/labels) on the frontend, eg. in language switcher.

I would avoid UTF8 page names and urls if there's no specific need.

  • Like 2
Link to comment
Share on other sites

Thanks @tpr - at this stage all my ML language questions are just for frontend translation purposes - at the moment the admin will only have English speaking editors (using content supplied by Português speakers), so I haven't bothered to load a language pack to translate the admin yet.

Thanks for the tips re latin vs cyrillic/chinese etc and not bothering with UTF8 page names - there has been no requirement for this - I just wasn't sure what was considered best practice.

Link to comment
Share on other sites

I think it should be "Português" because it's directed at people that want the content in Portuguese. Usually that doesn't make much difference, but think of the extreme case of a website in Chinese (again Chinese, but for the other question) — if you have the language links in chinese, the people to whom they concern won't understand them.

  • Like 1
Link to comment
Share on other sites

42 minutes ago, diogo said:

I think it should be "Português" because it's directed at people that want the content in Portuguese. Usually that doesn't make much difference, but think of the extreme case of a website in Chinese (again Chinese, but for the other question) — if you have the language links in chinese, the people to whom they concern won't understand them.

Thanks - that was my thought, but being an ignorant English speaker I just wanted to check with the experts :)

Are you in agreement with @tpr about not bothering with UTF8 page names for latin languages?

Link to comment
Share on other sites

2 hours ago, adrian said:

Are you in agreement with @tpr about not bothering with UTF8 page names for latin languages?

 

I think it depends on your content approach. For instance, if the client has a complete operation in Brazil, it will be great to both users and SEO to have the URLs also translated like so:

example.com/about-our-products

example.com.br/sobre-nossos-produtos (.br is optional).

example.com/pt/sobre-nossos-produtos (.pt can also be "pt-br" or "br" if you are targeting specifically Brazilian Portuguese speakers)

But in the case of just translating the content (not fully localizing it to the market) and/or you already have a bilingual site with the same English URLs, keep them in English only. :)

And on the topic, avoid at all costs using country flags on the front-end. Unless you're targeting specifically like I said. :)

  • Like 4
Link to comment
Share on other sites

17 minutes ago, Sérgio said:

And on the topic, avoid at all costs using country flags on the front-end. Unless you're targeting specifically like I said. :)

Good tip! I haven't think about that it could be an issue although the sites I made/designed so far are OK with flags. Seems that I can throw away my fine-tuned/optimized svg flags :) 

  • Like 2
Link to comment
Share on other sites

1 hour ago, Sérgio said:

I think it depends on your content approach. For instance, if the client has a complete operation in Brazil, it will be great to both users and SEO to have the URLs also translated like so:

example.com/about-our-products

example.com.br/sobre-nossos-produtos (.br is optional).

example.com/pt/sobre-nossos-produtos (.pt can also be "pt-br" or "br" if you are targeting specifically Brazilian Portuguese speakers)

But in the case of just translating the content (not fully localizing it to the market) and/or you already have a bilingual site with the same English URLs, keep them in English only. :)

And on the topic, avoid at all costs using country flags on the front-end. Unless you're targeting specifically like I said. :)

Thanks for your thoughts!

Just to clarify though - I am definitely translating the page names to Portuguese - I was just wondering whether or not the page names/urls should be UTF8, or whether characters with accents etc should be automatically converted - eg. ê to e

It sounds like most of you with latin languages allow the automatic conversion, so that's what I am going with.

In this case there is no need for a different subdomain, but I will be going with a two letter language code in the URL to define the language.

I was planning on a language switcher, but it was going to be a text dropdown most likely, rather than country flags. Can I ask whether it's the flags specifically, or any type of language switcher I should avoid at all costs? And if not, what is the best approach to allow users to switch without needing to provide a separate subdomain which doesn't make sense in this case.

Thanks for everyone's thoughts - I really feel a bit lost on best practices with this!

Link to comment
Share on other sites

Quote

Just to clarify though - I am definitely translating the page names to Portuguese - I was just wondering whether or not the page names/urls should be UTF8, or whether characters with accents etc should be automatically converted - eg. ê to e

2

I agree with @tpr on avoiding utf-8 URLs, like, "/pt/apresentação/" for (/presentation) as there's no real need of it for Portuguese. 

Quote

I was planning on a language switcher, but it was going to be a text dropdown most likely, rather than country flags. Can I ask whether it's the flags specifically, or any type of language switcher I should avoid at all costs? And if not, what is the best approach to allow users to switch without needing to provide a separate subdomain which doesn't make sense in this case.

 

Avoid flags to represent languages unless you're targeting a specific country > language. Eg. Brazil's flag for text is in Brazilian Portuguese, not Portugal's flag and vice-versa. This is only a UX good practice, though. :) 

Language switcher is fine. PW's language profile is a good example, although you can only show the language's abbreviation instead of its full name, so EN and PT are fine. I still prefer PT instead of BR unless you will have both Portuguese versions of the site, in this case, use BR ou pt-BR / pt-PT.

Regarding the domain, Google has a good documentation about it: https://support.google.com/webmasters/answer/182192?hl=en

 

  • Like 1
Link to comment
Share on other sites

I agree. No need at all for utf8 on urls.

PS: good advice with the flags. I hate to see the brazillian flag representing the Portuguese language in international sites, and I'm sure Brazilians feel the same when it's the other way around. A flag represents a country, not a language.

  • Like 2
Link to comment
Share on other sites

11 minutes ago, Sérgio said:

Avoid flags to represent languages unless you're targeting a specific country > language. Eg. Brazil's flag for text is in Brazilian Portuguese, not Portugal's flag and vice-versa. This is only a UX good practice, though. :) 

2 minutes ago, diogo said:

A flag represents a country, not a language.

Very good point guys - sorry I hadn't thought about it that way!

 

12 minutes ago, Sérgio said:

I agree with @tpr on avoiding utf-8 URLs, like, "/pt/apresentação/" for (/presentation) as there's no real need of it for Portuguese. 

So to clarify a little further (just because I am still learning), what about: "/pt/apresentacao/" vs "/apresentacao/". You've all convinced me not to do UTF8 page names, but what about including the "pt" url segment vs setting a session variable? I realize that I don't yet know how PW remembers the language selection between page loads if it's not in the URL - is it automatic, or do I need to handle that myself?

 

15 minutes ago, Sérgio said:

PW's language profile is a good example

Regarding the domain, Google has a good documentation about it: https://support.google.com/webmasters/answer/182192?hl=en

Thank you - I had forgotten about the PW language profile and I will definitely read that Google link also.

In my case it is aimed at Brazil, rather than Portugal, but I'd still rather refer to PT than BR - I think it makes more sense.

 

  • Like 1
Link to comment
Share on other sites

Quote

So to clarify a little further (just because I am still learning), what about: "/pt/apresentacao/" vs "/apresentacao/". You've all convinced me not to do UTF8 page names, but what about including the "pt" url segment vs setting a session variable? I realize that I don't yet know how PW remembers the language selection between page loads if it's not in the URL - is it automatic, or do I need to handle that myself?

 
 
 
 

Imagine this case:

- The site has English as default language and Portuguese (pt-PT) as an alternative and you decided to suppress the language code on the URL, like in your example above. Everything looks fine but a new page is added with a name that is ambiguous, like '/actual'* (which is a false cognate, as it means 'current' in Portuguese).

Event if PW's handle the routing fine, what about the users? What language is the page in if they only see the URL? So, a pt/actual/  will be better. 

 

* 'Actual' is used just as an example, as it's now spelled 'atual', after Portugal, Brazil, and other Portuguese-speaking countries  agreement on vocabulary issues back in 2008 I think.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...