adrian

@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.

Hey guys, Just about to do my first ML work and feeling like a bit of a noob I have a site with several branches with the same templates and similar content but each one will have different language requirements - some will be English only, but the first ML one will be both English and Portuguese. Future branches will probably be English and Spanish and then who knows what others might be. I am wondering if there is a way to hide unnecessary languages from the branches that don't need them. I will need this to work for page names, titles, and all other fields. I will be making use of the ML features of the Profields Table field too, if that has any impact on how to make this work. Thanks for any ideas - maybe it's very easy and I just didn't RTFM properly

Ok, check out the latest version. Any panels that are checked here won't be available to superusers (and other users with tracy permission) if they have the "tracy-restricted-panels" permission. Let me know if that works for your needs.

I haven't set up that tracy-debugger-superuser yet - that was just an idea at this stage. What I am asking you is whether that approach would be best, or whether it would be better to go with a permission that could be added to certain superusers that limits the panels on their Debug bars. I think the second option would give more flexibility - what do you think?

Don't forget about $this->halt() rather than using exit/die https://processwire.com/blog/posts/processwire-2.6.8-brings-new-version-of-reno-admin-theme-and-more/#new-this-gt-halt-method-for-use-in-template-files

Maybe I could add a checkbox list of panels so that you can check off panels that aren't available to special restricted superusers? Do you think that would take care of all your needs with this one approach?

New User Bar config settings for changing the position of the bar, as well as an option to also display it for users who also have Tracy Debug Bar permission - gives quicker access to the admin and edit links, as well as any custom links you set up. Also fixed a bug where the User Bar wasn't showing in Production mode.

Hey @Macrura - just looking at this part of your question again - is this the key thing you want changed - the ability for Tracy to not be shown for all superusers? If you want I could check for a new "tracy-debugger-superuser" permission. This would only be considered if it exists and if it does, superusers would only be able to see the Debug bar if they also have that permission. Is that what you are looking for? or is your issue answered by these posts? https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127746 https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127747

Hi @Naz - glad you like the module and welcome to the forums. I can totally understand the issue you are having with the way I have the configuration set up. Ideally having it by template would also be useful - unfortunately I don't think it will be a simple change so I am wondering if we can figure out why you are needing the field pairing to be set up if you have matching numbers of fields in the CSV file. Are you using the latest version of BCE? Could you perhaps send me a test CSV file to work from?

Thanks for getting back to me. @BrendonKoz - I think if everything is working fine for @cstevensjr as it is, then maybe we should just leave until there are issues for others - unless you feel strongly that the change should be made - in which case maybe you could elaborate so that @cstevensjr agrees that the change needs to be made. I'll leave this up to you guys to figure out if that's ok