wishbone Posted March 15, 2013 Share Posted March 15, 2013 I have a simple site which should be in two languages. no language support in admin needed. Which is the easiest way to achive this? I don't mind two trees, but don't know how to deal with it. Is the LanguageLocalizedURL module the one which does it? I've read on Ryan's new implementation of mulitlingual site support in the 2.3 version http://processwire.com/talk/topic/2979-multi-language-page-names-urls/ - is it already advisable to use it? Link to comment Share on other sites More sharing options...
ryan Posted March 16, 2013 Share Posted March 16, 2013 Since your site is simple like you say, I would just make one branch in the tree per language. i.e. /en/ /about-us/ /contact/ /es/ /quienes-somos/ /contacto/ If you want to be able to translate static text in your template files, you'll want to also use code internationalization. Solutions like LanguageLocalizedURL and the new LanguageSupportPageNames become more valuable when the scope of maintaining two trees (like above) becomes too much work. But if it really is a simple/small site, then keep it simple. 1 Link to comment Share on other sites More sharing options...
yellowled Posted March 16, 2013 Share Posted March 16, 2013 Ryan, what is your threshold for “simple” here? I'm about to port a bilingual site to PW, but there is some wiggle room as to when it's due, so I could wait for 2.3. The possibility of core multilingualism sounds appealing, although I have also managed to set up a test site using LanguageLocalizedURL. But it does involve some work, which I might want to skip here since this is kind of a pet project. So, any rules of thumb as to when to use what? Link to comment Share on other sites More sharing options...
ryan Posted March 16, 2013 Share Posted March 16, 2013 Ryan, what is your threshold for “simple” here? I don't know what the threshold would be. But for me, if I was having to manage more than 10 pages separately in two languages, then I'd probably want to start using multi language fields and page names. Of course we've had multi language fields for quite awhile now. But the new LanguageSupportPageNames module really makes them worthwhile. I have to launch a site in April that uses this system, so I expect this to be production-ready in the core by then. Though it's all working in the core now (in the dev branch) and has been stable for me during development of this site. Link to comment Share on other sites More sharing options...
yellowled Posted March 16, 2013 Share Posted March 16, 2013 But for me, if I was having to manage more than 10 pages separately in two languages, then I'd probably want to start using multi language fields and page names. Yeah, there's always the looming question „How many pages actually have similar content in both (or all) languages?“. I guess there really is no ballpark for this question … anyway, this multilang core functionality is another option, which is always great. Link to comment Share on other sites More sharing options...
wishbone Posted March 16, 2013 Author Share Posted March 16, 2013 with the trees, I had the problem how to make the menus only use the tree items of their language tree... well, could have been done with different nav templates for each language, excluding part of the tree. But I worked myself into LLU, it's nice, because it switches each site to its respective language pendant. Does it mean, this LLU will be deprecated? I didn't have time to wait for April. Link to comment Share on other sites More sharing options...
ryan Posted March 18, 2013 Share Posted March 18, 2013 Does it mean, this LLU will be deprecated? Not as far as I know. But this is a better question for Soma. From what I understand, LanguageLocalizedURL works very differently. LanguageSupportPageNames and LanguageLocalizedURL modules are not equivalents in functionality. But I think there is still some crossover, so individuals would probably want to evaluate both to see which meets their particular needs better. Link to comment Share on other sites More sharing options...
Soma Posted March 18, 2013 Share Posted March 18, 2013 I already mentioned soemthing about this in here http://processwire.com/talk/topic/2979-multi-language-page-names-urls/?p=29567 LLU just exists because of the lack of what now becomes a core feature. It doesn't make sense to have a slow parser if there's a performant way to do it out of the box now. It just has some small features added which aswell could be done on a per site scenario with some code or module. If core support will have language segments /en/, /de/ support there will be no reason to have LLU anymore. Link to comment Share on other sites More sharing options...
ceberlin Posted January 5, 2014 Share Posted January 5, 2014 One more question about i18n. (I am exactly at the point of choosing between language trees or i18n for a new project, and just saw the i18n video): Assuming I have a template and using the i18n strings. Then I add that to the template path to the admin language support settings. Fine so far. What, if I ever need to rename the template later for some reason. Is then every translation lost or is it kept (updated there by PW)? Link to comment Share on other sites More sharing options...
ryan Posted January 11, 2014 Share Posted January 11, 2014 What, if I ever need to rename the template later for some reason. Is then every translation lost or is it kept (updated there by PW)? If you rename the template, then you'd also have to rename the associated language file, otherwise they'd be disconnected from each other. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now