I havent done anything with canonical urls, thats a good thought. regarding
the locale parameter, the domain always overrides the parameters. the one
time that is a problem is when you click to view the published or draft site
inside the cms in a non-default locale.. the cms always sticks inside the
current TLD when viewing a page which will make you view the default
locale's record instead. any ideas on this? should we make it so that
using a ?locale param overrides the TLD or switches the domain to the
correct one for the record? any other options?
On Tue, Jun 7, 2011 at 5:26 PM, Ingo Schommer <i
...@silverstripe.com> wrote:
> Hey Chris,
> Just for reference, I'm pasting my email to you from a while ago here -
> maybe somebody else wants to pick up these suggestions and
> turn them into patches? :)
> i did notice (after i posted the code to github) that there is no
> content-language metatag, so i extended the MetaTags function to add
> that locale in.. im not sure if something is broken in 2.4.4 that
> makes it not appear or if its just code that should be included. this
> bug is causes problems with ss18n javascript.
> See http://open.silverstripe.org/ticket/4858 - the W3C recommends
> <html lang=...> over <meta> tags.
> On 3/05/2011, at 6:37 PM, Chris Bryer wrote:
> hey guys,
> I built a little module to handle the 'top level domains' approach
> sigurd mentioned, the code is on github and i'll probably be
> submitting it as a silverstripe module shortly:
> https://github.com/cbryer/Translatable-Domains
> The module lets you register what locale each top level domain should
> use, then enforces the locale. if a request is made for an english
> page on a german domain, it will try to find the german translation
> and show that if it exists and if it doesnt, it'll find the requested
> page and set the url to the correct top level domain. my customer has
> several domains all with the same batch of tld's, and the module
> handles this domain-masking situation pretty well, but if you have
> mysite.de and anothersite.fr, it wont be able to handle a switch
> between those two, it'll only handle a switch between mysite.de to
> mysite.fr.
> i also realized that i could test this configuration locally by
> setting up additional virtual hosts (localhost-de, localhost-fr, etc)
> to mimic different tld's, so i built that into the module and included
> directions to set it up as well.
> I'd leave the environment specific switches (isLocalhost()) out of the main
> logic,
> and move that to mysite/_config.php which could set different url/locale
> maps
> based on environments. Stuff like stripping out HTTP port information
> should
> apply for all environments. I was about to suggest PHP's built-in
> parse_url()
> for TLD detection, but then remember that it doesn't deal with double TLDs
> like co.uk heh.
> Either way, I'd try to find a more solid way to parse URLs then handrolled
> regexes.
> i did a bit of research and google seems to recommend handling multi-
> lingual website urls by using different top level domains if you can
> afford all the domain registrations, primarily because the domain name
> has a country attached to it and users have a better idea what the
> language of the resulting page will be just from looking at the base
> url. Google does recommend different strategies depending on target
> audiences and cost.. if you dont want to buy a bunch of domain names
> you may want to use subdomains if you want to target a global audience
> or you may want to use subdirectories if you have a regional audience
> that is multi-lingual.
> Are you ensuring that each URL is canonical, or redirects appropriately?
> E.g. what happens if I call
> mywebsite.de/mypage?Locale=fr_FR on a page with german and french
> language?
> It'd have to ignore the Locale parameter, or redirect to the french
> version.
> Same goes for multiple TLDs pointing to the same language -
> maybe it should inject <link rel="canonical"> in SiteTree->MetaTags()?
> It looks like the talk in this thread is suggesting one approach being
> built into the translatable module, however i think this choice could
> come in separate modules instead of baking it all into the
> translatable module.
> Given that Translatable is now a module, I don't see a reason why we can't
> add this capability to the codebase. It'll need some unit testing,
> and more peer review, but in general I see per-TLD routing
> as quite essential for multilingual sites. If you're worried
> about maintenance and commit access of this addition, I'm sure we find a
> workable solution.
> Thanks!
> Ingo
> --
> You received this message because you are subscribed to the Google Groups
> "SilverStripe Core Development" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/silverstripe-dev/-/aW9GTm1GVWxNa2dK.
> To post to this group, send email to silverstripe-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> silverstripe-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/silverstripe-dev?hl=en.
