I agree #5 and #4 seem like good default modes that are easily to set
a site to. I don't see one as outright better or worse; personalities
and the scope of the project will determine which mode is more
relevant for that particular project.
Sigurd
Ingo, what was committed or decided in the end, or is the jury still
out?
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
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.
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.
Thanks Ingo,
My time has been split between iOS development and building a foxycart module for silverstripe lately, and i can probably get back to this in a month. In the meantime, if anyone else wants to add patches that would be great.
regarding the $ContentLocale flag, thats awesome theres a fix for this. I didnt see anything about that in any docs like http://doc.silverstripe.org/sapphire/en/topics/translation. itd be a nice recipe to document.
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?
-Chris
Override in which way? Browser language detection? Google?I'm not aware of any built-in domain logic to Translatable in 2.4,so that shouldn't interfere with things.
You could influence this by customizing SiteTree->AbsoluteLink().
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.