tpr

I believe you should use the built-in string translator, but here is a simpler solution. It's probably not the most optimized one but it should work - put it in _func.php: <?php function getTranslations() { return array( "Read more" => array( "nl" => "Lees meer", "de" => "Weiter lesen" ), "Must see" => array( "nl" => "Must see", "de" => "Muss sehen" ) ); } function myTranslate($key, $locale = '') { if($locale == '') { $locale = $user->language->name; } $translations = getTranslations(); return (array_key_exists($locale, $translations[$key])) ? $translations[$key][$locale] : $key; } // usage echo myTranslate("Read more"); // current user's locale echo "<br/>"; echo myTranslate("Read more", "de"); // DE echo "<br/>"; echo myTranslate("Read more", "es"); // non-existing locale: original string ("Read more")

Dat rotation! Try to locate the cause using the Inspector, it's probably a CSS transform / keyframe animation collision.

I could get twig files into the admin translator but I couldn't echo them. I'm not sure whether I tried adding the path as the second parameter but probably not. Unfortunately I can't check this now because I'm using another template engine. What I do now is a simple function - optional context/textdomain get their default values in the function if not set: t('String to translate', 'optional context', 'optional textdomain') This works fine but because it doesn't contain "__" it won't appear in the admin translator. It' a nuissance because I have to manually list them in my _strings.php file, but for me it's better than having to edit strings in several files.

No biggie, but a 404 error occurs when using "Admin Theme Reno Roboto Colours" and allowing CSS maps in the Inspector (default setting is on I guess). The problem is that the notification system reports it every time when the Inspector is open: "404 occurred: /site/modules/AdminTheme/AdminThemeReno/styles/blue-robot.css.map" Removing the last lines from the roboto colours css files works but perhaps it shouldn't work this way by default.

Thanks, I will check that next time. Now I'm using Latte and made a handy translation helper function that adds the file path (= textdomain in PW, as I learned) as the second parameter automatically (just like what you suggested). Doing so I can have all custom string translations in one file (_strings.php).

Minor fix for a notice right after installing the module (undefined index). Doesn't affect anything. PageimageRemoveVariations_0.0.3.zip

I got the same problem, having a slider (carousel) with the first N pages, then the rest are listed below that (and paginated). Using "start" screwed things up. However, getting pages to exclude first and then building up the pages to paginate worked: $carouselItems = 2; $itemsPerPage = 5; // get page IDs to exclude $carouselItemIDs = wire('pages')->find('limit=' . $carouselItems . ', sort=-publish_date')->id('|'); // get pages for pagination (without carousel pages) $myPages = wire('pages')->find('id!=' . $carouselItemIDs . ', template=recipe, limit=' . $itemsPerPage . ', sort=-publish_date');

Same feelings here. My current PW project is a much simpler site (recipe blog), what makes it a bit more difficult is being multilanguage. Making relations between recipes, ingredients, etc was a breeze. Achieving this in other CMSes I know were much more problematic, even on a single-language site. In PW I could solve all the basic stuff without any modules. Of course I use some for my convenience - Page Field Edit Links, Admin Template Columns, SEO, Page List Image Label.

Nice big screens! On "multiple admin columns" you mean this module? It's new to me, will try tomorrow. http://modules.processwire.com/modules/admin-template-columns/

I have a 21:9 ratio screen and so far I wasn't able to fill it horizontally For those who need a closer look: body { max-width: 66%; transform: scale(1.5); transform-origin: 0 0; }

Is there any max-width set on the body in the new release? Sometimes I feel it would be a good idea. On very large screens fields are way too wide. Of course I can add this CSS to the admin myself but perhaps something like this could be beneficial for others too: html { background: #E0E4EC; } body { max-width: 1280px; margin: 0 auto; }

I meant another foreach loop. $csu = $pages->find("template=crms-updates, crms_status_updates=$page, sort=-crms_start_date"); if ($csu) foreach($page->crms_status_updates as $csu) { echo "<strong>{$csu->crms_start_date}</strong> |"; echo " {$csu->crms_comments} |"; // handle multiple page titles foreach($csu->crms_show_contact as $csu_page) { echo " {$csu_page->title}"; } echo nl2br("<br />"); } (ps. I recommend leaving the styling part to the CSS (and remove -es from php)

If you set the field to be multiple then you should get its values as a (PageArray), that is, using a foreach loop. Your example doesn't tell if you are using a loop or not.

I know about language alternate fields but it doesn't help much in my current setup. Thanks for the suggestion. I think I will go with the Page Field Edit Links module. It's only one extra step.

The problem is that not only different page titles are needed but page names too. And another twist is that users may want to add completely different tags per language to a page.

Or just say you are too oldschool and print them on paper

I agree, but from the client's POV it is not so convenient to add tags, then go to tags and translate. This would be the best, however, considering the available features. I have only 2 languages now and solved this with 2 fields relatively easily but it's not nice. I'm still hesitating on - forcing the client to translate tags manually, or - save only simple text fields (so no Tags pages to create at all) or leave as it is.

I'm having the same issue and there are a couple of related issues. I have an autocomplete Page field to add tags (also tried AsmSelect and other types). only the default language "title" is saved field "name" is saved properly only if the admin user language is set to the default language auto "name" generation works only if user lang == default lang (eg. from "title" field, in template Family - Name format for children) non-default language is not activated It's really annoying. I think I have to set up one field for each language but I guess I won't get away without a hook even so.

Interestingly inline ckeditor field contents are not saved after the above fix, so better not to use it (tested on 2.6.0, 2.6.6) Update: Fixed! See #57 above (had to add .parent()).

Here is a dirty quick fix - perhaps someone could make it nicer. 1. Append this to skin.js (/site/modules/InputfieldCKEditor/skins/lightwire/skin.js) // inline editor toolbar position fix // needs changes in editor.css, editor_gecko.css, editor_ie.css $('.InputfieldCKEditorInline').click(function () { var inlineToolbar = $('#cke_' + $(this).attr('id')); if (inlineToolbar.length) { $(this).parent().after(inlineToolbar); } }); 2. Append this to editor.css, editor_gecko.css, editor_ie.css: /*inline editor toolbar position fix*/ .InputfieldCKEditor { position: relative; } .cke_float { bottom: 100% !important; top: auto !important; left: 0 !important; right: auto !important; }

The inline editor toolbar is added as the last child to the body so there's no connection with the editor itself. The easiest thing I have in mind is to append the toolbar to the editor and set a pre-specified bottom position in CSS, eg "bottom: 70px". So it could inherit the editor width (100%) and grow upwards (useful if editor buttons break to multiple lines).

@renobird Looks like a false alarm, it only appears in SlimJet (WebKit). Checked in Firefox, Chrome, IE and there were no line breaks.

Tab text goes multiline here if there's a space inside: "white-space: nowrap" solves it.

Off: I remember a project manager asking for a "read-only source code" to give it to the client. Didn't happen

I have installed these modules to get Twig support on a multilanguage site: Template Twig Replace (Template Twig Replace Language Support) ProcessLanguageTranslatorTwigSupport Everything went fine until I tried to use "__" functions, eg. {{ __('my_string') }} The string showed up in the Language translator inside PW and I could translate it. However, I couldn't display it on the site. What am I missing? Ps. I was able to access these translations with plain PHP and with another templating system.