cream

...oh yes, you are right. The error does come back if I uninstall Tracy.

Thanks, @adrian, for the quick response! The most peculiar thing happened; as I went to install Tracy and decided to try exporting once again just because before diving into Tracy's settings, the export worked as it should. No error message no more! So all's fine now. Sometimes these things just go way over my head. Sorry this took some of your time too!

Howdy, I have BCE 1.3.8 installed and just upgraded from ProcessWire 2.7.2 to 3.0.36. When I Export pages to CSV, the created file starts with <br /> <b>Notice</b>: Trying to get property of non-object in <b>[...]/site/assets/cache/FileCompiler/site/modules/BatchChildEditor/ProcessChildrenCsvExport.module</b> on line <b>159</b><br /> and the actual csv-formatted data starts after that. Any thoughts?

Howdy, Has anyone yet started to add translations for the new goodies of PW 3.x?

Thanks for sharing your solution to this, Zeka! The default behaviour is not good.

Wow, what a nice surprice to come back to office after the weekend and find so detailed answers! @Sérgio This code sample and the notion of just changing the language are invaluable. I should have guessed the simplicity, this being ProcessWire after all... Next I shall read Ryan's case study (which I believe will be enlightening!) and check adrian's Migration module in light of this. Thank you for pointing these! @hheyne Thanks for this recolletion! It sure helps me to grasp the way of thought, and proves it's not a big deal after all. @dragan As LostKobrakai already answered, they use a program that has a kind of memory of commonly used phrases and translations for certain words for a brand, so that everything stays in line and reduces the actual translating work tremendously. For starters. It's quite fascinating really, here's a link to an overview of the technologies if you're interested: http://maris.fi/en/faq/translation-memory/ It would also be irrational way to use time customer is paying by clicking through the admin interface and try to cover every single page, tab and field individually and with no way to see the whole context at a glance. This is not a small site we're talking about here after all.

Hi! The translator sent us a huge list of file formats their software's exports and imports supports, including json, xml, csv and even html. So it won't be a problem. Do you have an example on how to go about exporting from and importing to ProcessWire again? Some module perhaps? I've tried adrian's awesome Batch Child Editor, but it doesn't seem to support multi-language fields.

Hi all, We have this huge website (over 7000 pages and a few dozen templates). We've used TextLanguage and TextAreaLanguage fields for all textual fields, and all image and file fields have their own description input boxes for different languages too. Now we'd need to export all pages and send them to our translator so they can translate all site contents with their specialized programs, and a way to import the translations back to our site alongside the content in original language. Has anyone done anything similar to this? How did you solve it? Maybe there already is a solid way to do this, or an idea we've not thought of yet. Thanks for any thoughts!

Can this module be used to export pages, add translations for content, and import them? We have this huge website (over 7000 pages). We've used TextLanguage and TextAreaLanguage fields for all textual fields, and all image and file fields have their own description input boxes for different languages too. Now we'd need to export all pages and send them to our translator so they can translate all site contents with their specialized programs, and a way to import the translations back to our site alongside the content in original language. Is this possible with BCE? I've tried to export site contents, but can't figure out a way to include image/file descriptions, or any textual field's contents in other language(s). This module has already been a huge help when initially building this site in question. We created most of the pages with Ryan's Import Pages from CSV module, and were able to modify them in batches with BCE quite a few times during further development. Massive time savings!

So this was it! Seriously, this is needed. Or at least mentioned in the $input docs.

Thanks, Will test these further some day, I've cought up in other projects so this has hibernated (and will probably stay like that for a while). Anyway, crosslinking is good for your health, so read this too if you're looking for solution ideas: https://processwire.com/talk/topic/11100-disable-a-language-on-a-multilanguage-site/

Just posting a link to relative thread (with no working solution yet, as I'm too deep in other projects right now to test more): https://processwire.com/talk/topic/10467-allow-translators-to-work-on-hidden-language/ If anyone comes up with a no-hassle solution to this, I'd be eager to read about it! Might help many others too.

Thanks, LostKobrakai! This does redirect to 404 (woohoo!), but changes the url to /http404/, too. That's better than the front page, but the best would be to leave the url as is and just show the 404 there (I know, didn't phrase it like that previously, sorry! Getting greedier here). I believe this isn't so easily doable without better understanding of PW's inners and .htaccess, though, so this'll do great for now. Landing to /se or /en (without the trailing slash) however don't trigger the redirect in your suggestion, so we're back in the drawing board with that bit. Progress: RewriteRule ^en(.*)$ /http404 [R=307,L] RewriteRule ^se(.*)$ /http404 [R=307,L] Further suggestions from .htaccess gurus (and wannabes, too) are most welcome!

Wow, thanks! I couldn't get your "something like this" example to work as is (obviously), but after some tweaking I think it's mostly there. Now I have this at the beginning of the .htaccess file: RewriteRule ^en(.*)$ / [R=307,L] RewriteRule ^se(.*)$ / [R=307,L] Pros: - Redirects also the non-translated front pages (/en and /se), not just the content pages (for example /en/some-page). Cons: - Will also redirect any URL that starts with letters "en" on "se" in the default language, for example "/enigma" or "/second". - Redirects all to domain root, not to 404 page. If there's a way to get rid of the cons while keeping the pros, I'm all ears. Thanks for the awesome answers this far! Also yup, 307 is on purpose (or would Processwire work better with 302 or 303 in this situation?). The redirect is temporary, because when the translations are ready everything has to work as if the redirects never were there. There's no sitemap.xml (yet), but the domain has been added to Google Webmaster Tools, just without a sitemap.

Thanks, @Christophe I haven't yet noticed the Languages > en > Settings > Status, which of course is the most logical place for site-wide language settings. D'oh! Enabling the "Hidden" checkbox does redirect the urls with language code to 404 page, whis is exactly what was needed as a quick fix for now. Thank you again! However, now we (or our customers, to be more precise) can't add in the translations, as the language tabs in each field in the page edit page are hidden. So the hunt for a right .htaccess rule continues; I haven't found the right copy+paste-able rule(s) just yet, as that's still all I can manage. Will focus on googling RewriteCond and RewriteRule next as per your most helpful suggestion!

Hiyall, I have the same problem, with Processwire 2.6.1. A multilingual site that was published with only the default language content. The translations will be added afterwards, and for now I've just commented out the language switcher (not sustainable!). Problem: Google finds all the not-yet-translated pages, and in fact favours them rather than the default language pages, which don't show in the search results at all. All pages have the "Active?" checkbox unchecked in these not-yet-translated pages. How are the pages still accessible? Before there's a fix in the core for this bad behaviour, I'd be happy to get some help with this quick'n'dirty .htaceess method to prevent these pages to be seen, but my .htaccess skills are still in the level of copy+paste. And the .htaccess method ain't good in the long run anyway, as clients would have to call us every time they've finished a translation and want it live. But before then we'd really need this to work. My attempt in the .htaccess: RedirectMatch 307 /en/(.*) /$1 RedirectMatch 307 /se/(.*) /$1 Not working. domain.com/en/yhteystiedot will redirect to domain.com//yhteystiedot?it=en/yhteystiedot (and shows an 404 page there), when I'd just like to get rid of the language code, ending up to domain.com/yhteystiedot. I'd be happy with redirect to a 404 or even the frontpage rather than the same url without the language code, if Google wouldn't find these not-yet-translated pages, but the default language pages (without the language code in the url) instead. Help, anyone?