adrian

Looking into it a little more, I have done both before and after in different scenarios: https://gist.github.com/adrianbj/6fd1b770d9ce7a7252b6 https://gist.github.com/adrianbj/e391e2e343c5620d0720 https://github.com/adrianbj/AdminRestrictBranch/blob/master/AdminRestrictBranch.module#L108 The first two I haven't used in a long time, but the last one I use regularly, but it's not manipulating the same way you are looking for. Perhaps you could see if one of the first two works for you though in 3.x - sorry I don't have more time right now to help debug.

Thanks for your thoughts @szabesz - it's a pretty complex site with most sections only relevant to people in the USA, although it adds value to users from other countries/languages to see the content from other regions, even though it's not translated. Down the road I can see that we'll have other sections that are only specific to other languages. Ideally, the overview pages will be translated into all these languages at some point. I think I have a decent approach now - I was just wondering what the general principle is when parts of a site are translated and other parts aren't, and dealing with setting the hreflang tag, but I think in my case I need some custom logic which is what I have done.

Not certain, but when I hook into ProcessPageList::execute I use AddHookBefore and it seems to work fine. The other thing that might be involved is the ajax check you have. In PW 3, the page tree is cached, so perhaps that ajax check is returning false, so it's not modifying what is returned?

Ok, so the problem with making a language not checked "active" for a pages is that the page disappears from menus when viewing in that language. So obviously I could either override that active check when generating the array of pages for the menu, or I could use another method for determining whether to show a hreflang tag for that language for that page. I don't want English-only pages hidden from users who are viewing the site in Portuguese, but I also don't want Google thinking that there is a PT specific page when there isn't. I am assuming it's good practice to keep the /pt/ in the URL even when there is no PT language version for that page? Otherwise if the page redirected to the default/english version, then if they navigated back to the pages that do have a PT version, then they would have to change the language again. I think the logical thing is to not use: $page->viewable($language) to determine whether to add a hreflang for the language, but I would love to know what you guys do when you have a site that is only ML for certain sections, but you want all sections to be available to all users - they can of course always use Google Translate for the other sections so I don't want them hidden/not active. Sorry for rambling - just trying to figure out what the best practice is here. Thanks in advance!

Hi @FrancisChung - I can't seem to reproduce this and I have been using those settings for over a year on one site. Is there a certain action that triggers the error or is it simply trying to view the page on the frontend? Could you possibly try on a fresh/different PW install? If you have Tracy installed, could you try: bd($p->id.':'.$p->status); on line 165 - after $p is defined on 164. It seems like $event->object is not returning a page object for some reason in your scenario, but I don't know why.

FYI - "FieldtypePageTable" is not related to ProfieldsTable at all. FieldtypePageTable is free and a core module, just not installed by default.

Sorry that was lazy of me to not look for that. So essentially it's all about the "Active" checkbox on each page. It's actually kinda weird to me that when you add a new language all existing pages are automatically activated in that language. Guess I need a little API script (or actually maybe some SQL will be easier) to deactivate all pages outside the one branch that is available in PT. Although I expect I still want the homepage and any direct parents between that ML branch and the homepage activated so that all segments of the URL will be in PT when requested - does that sound correct? That way I'd still get: /pt/cartoes-relatorios/baia-de-guanabara/indicadores/nitrogenio-inorganico-dissolvido/ rather than: /report-cards/baia-de-guanabara/indicadores/nitrogenio-inorganico-dissolvido/ where /baia-de-guanabara/ is the parent page of the one branch that is available in both EN and PT.

Maybe getting a little OT, but how is: $page->viewable($language) determined? Is it based on whether the page has an alternate "name" in the requested language, or some other means? I might actually take another approach, because it's actually only one branch of my site that has more than one language (english) at the moment, so it would be wrong to list the hreflang as having pt-br for the rest of the site. Any ideas please on the best practice approach to automate this?

Hey guys - as a few of you know, I am in the middle of my first ML site and was wondering about the hreflang tag. Using the recommended: $hreflang = $pages->get('/')->getLanguageValue($language, 'name'); to set the value in the hreflang seems to contradict what I am reading elsewhere. I thought that the hreflang tag must always include a country, in my case: pt-br. But I don't really want pt-br in the url - I really just want: http://mysite.com/pt/ rather than http://mysite.com/pt-br/ Now obviously I can set the hreflang another way, but it seems like most of you are doing it this way, so just wondering if it's actually ok to leave the country code off, eg. hreflang="pt" rather than hreflang="pt-br" Also, what about: x-default vs en-us for my default language? Thanks again for your advice! PS - I have gone with @LostKobrakai's approach of adding an iso field to the language template so I can easily define en-us (or x-default - still don't know what is best here) and pt-br, but I would still like to know why it seems that most are just using the two letter language code without the country code.

@Sérgio - that's a great case to make your point - I really appreciate your (and everyone's else) feedback on this - it's been very helpful. I'll be diving into the frontend side of things tomorrow so I am sure I'll have some more questions. Obrigado a todos

Very good point guys - sorry I hadn't thought about it that way! 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? 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.

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!

Hey @teppo - just noticed this notice - I think it might be new since installing multi-language support on the site. PHP Notice: Undefined index: Previous page name in .../modules/ProcessChangelog/ProcessChangelog.module:574

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?

And of course update the module compatibility to include 3.x

Or use the User Switcher in Tracy so you can test easily https://processwire.com/blog/posts/introducing-tracy-debugger/#user-switcher

Whenever I commit a new version to Github I always update the PW modules directory, so you should always be able to get the latest version (which is 1.3.6) that way.

Thanks - I understand that when using "language alternate fields" it automatically used the field based on the language name in the "_suffix" but are you saying it also works if I had two pdfs in the one files field named: "mypdfname.pdf and "mypdfname_portugues.pdf" - so if the user has selected the default English they will get the first one and if they select the dutch language the second one will be automatically linked to instead? I just did some basic testing and I don't see it functioning that way. What does work (and what I assumed I would have to do if I upload all language versions to the one files field), is this: $page->document_pdf->get("name*=portugues")->url obviously replacing "portugues" with the current language. Am I missing some other way to do this? I am actually thinking that separate language alternate fields will probably be easier for the site editors, but I am still curious to know if there is a different approach I am missing.

How about: Disabled Panels for Restricted Users or Panels Disabled for Restricted Users

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.

What do you guys do about multi-language versions of PDF documents stored in a files field? I want the correct language version of each doc served on the frontend based on the language selected by the user. Do I make use of the Language alternate fields in this case, or do you guys upload different versions to the one files field and have some sort of naming convention, eg "mypdfname_dutch.pdf" etc and then add the logic via the template API to server the correct version? Thanks for any advice.

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!

Great to hear! I am having troubles replicating this - any chance of getting access to the admin of the server so I can take a look? If not, could you perhaps test to see if there is some specific combination that causes this problem for you. Does it only happen with multilanguage fields? Any specific file/image settings that are needed? If you could start from a fresh PW install with default textarea and image fields and try to figure out what setting may be causing the problem that would be very helpful. I honestly haven't looked into it yet. I am glad that your workaround of changing the default language works for you. I think supporting ML importing could get tricky - how would you delineate between the content for each language? Would it be separate CSV "columns"? I guess if there was a column for each language for each field that is ML it should work. I don't have time to look into it at the moment, but I am actually starting on my first ML client site, so I will be learning lots more about ML and might get some insight into the best approach.

Thinking this through I think I would like to add a page field (checkboxes) on the parent page of each branch that is linked to the list of installed languages so I can specify which language field inputs should be available to all child pages in this branch. Now the catch is finding the hook that determines the languages to list. This may need to work with both multi-language fields and language alternate fields, although I am not sure about this yet. I haven't scoured thoroughly yet, but does anyone know the best hook for this?

Sweet - glad you are finding it useful. I am kinda keen on knowing what panels you use and what panels you restricted them to. I have actually been thinking about setting up a poll so I can find out what panels you guys are all using - would be helpful so I know which ones to focus on improving. I don't think this new version of the forums has the poll option though.