kixe

@ryan Module requires ProcessLanguageTranslator which is part of ProcessLanguageSupport. No effect on the error. Do you recommend to change that? Why? @Soma tried out all options. Still get the Error without changing the following. class ProcessLanguageTranslatorPlus extends ProcessLanguageTranslator { ... Error occurs because the class to be extended couldn't be found. How to prevent from an Error if a downloaded module extends a non existing or not installed class? Any experiences?

@soma thanks for your help in debugging. bug fixed. Got the following Error while trying to install the module via modules manager without required installation: Error: Class 'ProcessLanguageTranslator' not found (line 21 of /Users/c/Sites/processwire/sitet/modules/ProcessLanguageTranslatorPlus/ProcessLanguageTranslatorPlus.module) Installation via admin > modules is impossible(disabled) without required Installations. How can I fix this?

I have different languages in the backend, a template with a field of type float. I cannot save a float in other languages (polish and german) than default (english). The floats are rounded to full integer value and stored like this. added 30 October 2013 09:37 AM To prevent language troubles I am using a workaround now: input type text instead of float with a regex (settings > pattern): \d{1,4}([\.]\d{1,3})? For validation of a weight of max. 10,000 kg (9999.999 kg) with max. 3 decimal places, only the dot is allowed as seperator.

Thanks for the note. Correction is done.

I got it: I made the summary in my modules translatable like: 'summary' => __('Here comes the text'), This function does a second entity encoding. Is it useful to edit the following line in ProcessModule.module to prevent from double encoding? Line 128: $summary = empty($info['summary']) ? '' : htmlspecialchars(htmlspecialchars_decode($info['summary']));

Yes there must be one htmlspecialchars too much. Cannot find the second one, maybe until rendering the table as a form value? If I take away the first one it works. ProcessModule.module Line 128: $summary = empty($info['summary']) ? '' : htmlspecialchars($info['summary']); Line 182: $form->attr('value', $out); //call of modules > InputfieldForm/ InputfieldWrapper

update to Version 1.0.2 translatable German Language Pack comes with Module more configuration options simplification of color setup optimized Accesibility

When I get in contact with processwire after a recommendation of a friend the first step after installing was a look in the database. Why? I had bad experiences with a shop-system I used, which ended up in digging and modification of the source code to make it work properly. Finally the biggest problem was the database with its questionable structure and data redundancy. I said goodbye to the shop-system after. With processwire I felt immediately in love because of its super slim and clear structured database without redundance of course from which results a lot of opportunities to grow. But since I use multilanguage support in processwire it makes me a little gripes when I see the way of Language Implementation in the database. About the conventional structure as an example: users are stored in pages and passwords are stored fields 'field_pass' which refers to the page (perfect) Structural changes since multilanguage support: pages and fields either have data (information about language) stored in column titles like 'name1007' or 'data1007' (not really perfect) What happened while making processwire multilingual? The tablefield in the database 'name' in table 'pages' wasn't unique anymore. 'name' from now on would have to be a field 'field_name' like 'field_titel' with its own databasetable. Same to status. The status of a page should be stored in 'field_status'. Possible solution: There exists already a field 'field_language' which stores the language of the page 'user'. This field could store easily the language of every page. Every page in every language should have its own database entry and unique id, even the rootpage with parent_id '0' should have this. All name and status columns should be outsourced to fields. Language relevant columns like 'data1007' in fields are obsolete. As a result every field becomes multilingual automatically, because it references to a unique site. I know that many people Ryan first of all have spent a lot of time and work to make this great system available. And I have a lot of respect before this people. I am happy to use processwire and I love it. But since I run in problems when I decided to switch an alternative language to the default language burrowing around in the database I started to think about some facts. I am pretty sure processwire will run in problems following the pursued way. On the way making processwire to the worlds best CMS the database as the heart of the system should be young, healthy and proper.

@all thanks for the laurels @felix this shouldn't be a problem, most of the work is done. But first of all I would like to clear up the rights. I don't know who created the logo respectively who is the owner of the copyright license. Generally I am not in the theme of typefont licensing. Before I made the post didn't really thougt about that. Maybe somebody could bring some light in this issue ...

Think the problem lies here: core > fields.php function isNativeName() checks if field is an item of array $nativeNames. Found it searching for other stuff a few time ago. class Fields extends WireSaveableItems { /** * Instance of FieldsArray * */ /** * Field names that are native/permanent to the system and thus treated differently in several instances. * For example, a Field can't be given one of these names. * @TODO This really doesn't belong here. This check can be performed from a Page without needing to maintain this silly list. */ static protected $nativeNames = array( //NOT INCLUDED HERE: 'name1234' or what ever language id ); Have a look here too: http://processwire.com/talk/topic/4780-database-structure/

Had fun to create a webfont with only one single glyph: Processwire-Logo Unicode-Letter:  (Unicode Block "For Private Use") I created first an svg with inkscape and created the font-set with http://icomoon.io/app (very nice website!) Like it, use it, waste it. font-package with demo file here: attachment=1836:processwire_webfont.zip updated 23.11.13 (4 Glyphs: 'processwire', 'process', 'wire' and 'w') processwire_webfont.zip

Qotes (single or double) in the summary (Array Element of ModuleInfo) will be displayed '&quote;' or ''' which means the output of the html-source is: '&quote;' or '''. Didn't check the cause. Maybe better to avoid the use of quotes in the summary respectively in translations (.json).

@Yannick Are you sure? $p = new Password(); $hash = $p->randomBase64String(); // 100=length of string? too long for the forum ;-) echo $hash; // output example: 3JrVekq0ZRPVJadm8i601Z1 What do you mean with 'activate via GET' just transmit or more? All the best from Paris

I created a Modul which extends Language Translator (Core) Modul, with a select-field to choose translatable files not translated yet. But it doesn't work perfectly, because the language to be translated isn't set by default. Even if I use the Standard Language Translator, no translated files will be listed. Even then, if I have set translation files for all my languages. If I go to setup -> language, choose a language and start to edit a translation file, the language-to-translate will be set in the system. Now I can go to the Language Translator and it looks like I had expected: Just to be clear I am not talking about the user language. I think it would be useful either to have a Language Selector in the Module Language Translator to select the language before the files are (not) displayed, or to set a default language-to-translate, which will be displayed in the Head of Language Translator to be clear which language is in processing. I will have a deeper look to find a solution. 1 hour later: looks like it would work now. I initialized the modul with the users language by default, if nothing else is set (GET or SESSION) I made an update on github. Maybe its a better idea to make the Language-Translator a Child Page of the specific Language Page. ... or to go sleeping Good Night ... 17.10.13 Updated the Module today with a Language Switcher and a clear headline which let you know in which language you are. Working fine on my System now. Looks like: @experts: please check Get the Module here: https://github.com/kixe/ProcessLanguageTranslatorPlus or here: http://modules.processwire.com/modules/process-language-translator/

Sorry for confusing and wasting your time. Finally it was a cache problem. What I have meant wasn't the name of the language but rather the name of the rootpage in the default language (here: fr for default).

My solution, which works nicely: I put the following code on the top of my template. (example for French as default, German and English) $date_lang = array(); switch ($user->language->name) { case 'en': setlocale(LC_ALL, 'en_GB'); $date_lang[0] = "%A %B %eth %Y at %I:%M %p"; $date_lang[1] = "%B %eth %Y"; $date_lang[2] = "%I:%M %p"; $date_lang[3] = "%A"; break; case 'fr': setlocale(LC_ALL, 'fr_FR'); $date_lang[0] = "%A %e %B %Y à %kh%M"; $date_lang[1] = "%e %B %Y"; $date_lang[2] = "%kh%M"; $date_lang[3] = "%A"; break; case 'de': setlocale(LC_ALL, 'de_DE'); $date_lang[0] = "%A, den %e. %B %Y um %k.%Mh"; $date_lang[1] = "%e. %B %Y"; $date_lang[2] = "%k.%Mh"; $date_lang[3] = "%A"; break; default: setlocale(LC_ALL, 'fr_FR'); $date_lang[0] = "%A %e %B %Y à %kh%M"; $date_lang[1] = "%e %B %Y"; $date_lang[2] = "%kh%M"; $date_lang[3] = "%A"; } Then I created a page field, where I store a date unformatted (go to setup->fields->mydatefield->details-> date output format ->"None"). getUnformatted() is only needed, if the date is stored formatted. Finally I can insert the date like echo strftime($date_lang[0], $mydatefield); /* output(de): Freitag, den 11. Oktober 2013 um 12.52h * output(fr): Vendredi 11 octobre 2013 à 12h46 * output(en): Friday October 11th 2013 at 12:46 pm */ echo strftime($date_lang[1], $mydatefield); /* output(de): 11. Oktober 2013 * output(fr): 11 octobre 2013 * output(en): October 11th 2013 */ echo strftime($date_lang[2], $mydatefield); /* output(de): 12.52h * output(fr): 12h52 * output(en): 12:52 pm */ echo strftime($date_lang[3], $mydatefield()); /* output(de): Freitag * output(fr): Vendredi * output(en): Friday */ Maybe you have to check out which string in setlocale is working on your Server. Try different: setlocale(LC_ALL, array('fi_FI.UTF-8','fi_FI@euro','fi_FI','finnish')); //put out the first supported string echo setlocale(LC_ALL, 0);

BUG? I tried to change the default language to french (fr), which I set first to german (de) in the admin. What I did: I went to admin -> setup -> languages and changed entries for name and title and saved it. When I tried to edit other pages the names (pathes) didn't change. After looking in the database the entries for the homepage (id=1) in the fields "name" and "name1234" in the table "pages" retain the original value.

I want to set $user->language to the default language of the browser at first opening of the site. How can I prevent that it doesn't switch back, after the user changed it, or the user-language is stored in the session?

for nearly complete empty language pack look here: http://processwire.com/talk/topic/1220-translation-howto/?p=39542

@achabany broken link: https://rapidshare.c...33721/fr_FR.zip

I created an empty language pack. Go to: Admin > Setup > Languages Create a new language Drag & Drop the attached zip-file in the Language Translation Files Field. Start to edit the files. empty-lang_pack_pw_3.0.41.zip EDIT: Obsolete in latest PW Versions. Create a language pack by your own. Go to: Admin > Setup > Languages > Add New Save Press button: 'Find Files to Translate' Select all files in the box 'Translatable files in /wire/' Select files in the box 'Translatable files in /site/' which you want to add to your custom language pack Press 'Submit' Start translating Download zip or csv file by pressing the related button at the bottom of the page where translatable files are listed. Done

Thanks Ryan for the template. Looking for a solution to use a sitemap together with LanguageSupportPageNames I created a sitemapindex which is stored as a static file named sitemap.xml in the root-directory. It is working nicely. <?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>http://www.example.org/de/sitemap.xml</loc> </sitemap> <sitemap> <loc>http://www.example.org/en/sitemap.xml</loc> </sitemap> </sitemapindex> Now I am thinking about to create a sitemap based on the new google annotation: rel="alternate" hreflang="x" and your template. My question, how can I prevent the redirect of sitemap.xml to en/sitemap.xml or any other language dependent site, still using LanguageSupportPageNames for all the other stuff?

Cannot get the field 'name' in the current language. Example: $pages->get('/sitemap/')->name puts out 'seitenuebersicht', the default name, even if I switch to another language. In contrast the following api is working fine and puts out the current language. $pages->get('/sitemap/')->title; Is there a special reason of this? (I am using latest wire from dev-branch)

got it: public function init() { $this->addHookProperty('Page::player', $this, 'render'); } protected function render($event) { $page = $event->object; $embedCode = "... code ..." $titles = " ... code ..." $event->return = array('code'=>$embedCode, 'title'=>$titles); }

Like discribed in the helloworld.module of ryan I put the following code to the module: public function init() { $this->addHookProperty('Page::player', $this, 'render'); } protected function render() { $embedCode = "... code ..." $titles = " ... code ..." $event->return = array('code'=>$embedCode, 'title'=>$titles); } and that in the template echo $page->player['code']; But still doesn't work. What is wrong here?