lisandi

If you have never heard of graphics magick than teh reason might be that you have never worked with a serious CMS which has automatic image processing on board like TYPO3. It is actually much more recommended to use Graphics magick rather than Imagemagick as it is processing images much better. If you have TYPO3 installed and you have got on your server ImageMagick and GraphicsMagick avaialable than simply test out the differences. TYPO3 Installtool has a nice Checker about the major imageprocessing tasks needed. By the way TYPO3 is also using GD for some tasks. Espessially the compression of images is much much better with GraphicsMagick. And smaller images load much better ;-) TYPO3 is capable to use both ImageMagick OR GraphicsMagick and both together with GD! I really recommend to setup a testing installation of TYPO3 to test out the differences - you actually only need the Installtool for that! No need to setup the complete INstallation and of course you will need to have both ImageProcessors installed on your server. sorry it is in German but as you are German you will be able to read it Horst! https://www.cyon.ch/blog/GraphicsMagick:-Das-bessere-ImageMagick http://jankohermann.de/typo3-6-2-und-graphicsmagick/ In English http://wiki.typo3.org/GraphicsMagick simply install graphicsmagick in the imagemagick compatibility modus and you are all set: apt-get install graphicsmagick graphicsmagick-imagemagick-compat in TYPO3 you only need to set GM instead of IM and lots of other settings which are needed for Imaghemagick only - also sRGB needs to be RGB in GraphicsMagick and it will work!

Check out this here Pidelux: http://www.sorryopenerp.com/developers.html http://www.sorryopenerp.com/blog.html This site can't be taken seriously - sorry! ODOO has critics like Processwire has them and as you might know people splitted up from odoo years ago I guess you never have even tried to use Odoo, or Tryton or any other system of that kind! You will find critics for all kind of systems - also for Processwire i.e. here: The idea was actually to show some great examples of website builders which are very user friendly and odoo has a great one and TYPO3 has great stuff to do so in the backend and in frontent, Drupal has got it like Joomla and wordpress (check out the themes) The idea of my post was not to secure a developers workplace by blocking developments into that very userfriendly direction which makes developers to submit every smaller change to a website simply obsolete. --- Concerning "army of beginner developers" I would suggest you read the vitas of most people who post here in the forum and who build for or with processwire. I guess with Odoo you will find a much much higher percentage of qualified and non beginner developers - but developers with year long experience with all kind of CMS, ERP, Opensource Software solutions than with Processwire. Processwire is easy so that it attracts even a beginner and he/she can setup a website without any PHP know how! So you can setup an Odoo complete ERP,HRM,POS,ACCOUNTING,PROJECTMANAGEMNT,BLOG,WEBSITEBUILDER,.... and much much more in some minutes without any Python know how! Pretty similar! It is therefore not a good style to complain about beginners like you have been one for sure also at some point! Beginners of know much better what makes a Product a good product for the community as they are not so focussed of only one product like hard core old devs are already (focussed i.e. on only processwire, or only odoo) Odoo is playing in a total different league, which processwire will neverever reach! It is meant for total different usage and user groups! Huge companies, institutions, organisations etc. are using ODOO since years very successfully and since Version 8 it has now the website builder which is a very new feature! Nevertheless I guess that some people soon will move again over to Processwire after their announcements concerning the support of TYPO3 Versions. http://typo3.org/news/article/announcing-typo3-cms-45-extended-long-term-support-plans/

Hi spoetnik simply create a sub domain, redirect that to cloudflare and test it out. ;-) http://gtmetrix.com/reports/ttfp.eu/S354wbNr he comparison: http://gtmetrix.com/compare/gg834XCN/OVWroWa4 As you can see the % values already improved a lot but there is still huge space for improvements. You will realize also that your othervalues actually went up! what is not so good! page loading time doubled even - better would be to make it using have of the time from the first gtmetrix test and this is feasible. Give it a try!

Hi Spoetnik Interesting theme they have. I would recommend that you check your site again with gtmetrix and apply the changes they suggest. It will help you to get much more speed out of your site. http://gtmetrix.com/reports/ttfp.eu/gg834XCN - Try to achieve values higher than 95% in Pagespeed and Processwire and a loading time less than 1.2 sec Until now the site also has no SEO optimization - The module Nico is developing woudl be a great instant help for that problem too. Just install it and apply the seo values mentioned in there - fill out the fields. Most of all I would recommend enabeling gzip compression and as a next step using a supercharger like cloudflare to speed up loading times and to improve security and even give your customer some more nice features for free - as he needs to communicate with customers - i.e. uservoice etc. check it out. http://cloudflare.com Thanks for sharing

sensio insight is a good tool and used by Drupal8 a lot since they are on symphony. Security is quite important and most important is actually a lively reporting community!!! Which means the mor people are using processwire the more vulnerabilities probably also get discovered and reported. 1. I would start using PHP 5.5 ONLY and no more provide backwards compatibility. This will increase security a lot already. Simply make a cut and release a new version which is only compatible with PHP 5.5 and higher. TYPO3 7.0 was just doing that step and it is a huge speed (it is really fast!) and a huge security improvement already! OK some modules/extensions are not working but this is a very useful cleaning processes which forces developers to review and probably adjust and upgrade their modules.DON'T hang on those people which still want to use versions lower 5.5 and their arguments. Qualified and Serious Developers keep their stuff up to date and use also hosting surroundings which would allow deploying a Processwire Version which uses only 5.5 and is no more backwards compatible to lower PHP Versions. AND it will bring you more customers this is exactly what just happens since TYPO3 7.0 has been released. People like it so much that they like to switch even it has not all the modules which are working in right now. They like the new backend the new look and most of all they like the great speed increasement and SPEED is very important - I would say even more important than Keywords and all this other SEO stuff! And not seldom they also reduce the chance of vulnerabilities of your site! 2. Security is very important criteria for customers, especially from bigger companies and smaller ones actually most likely follow the "wind" - which means as soon as they will pick up a vulnerability from whatever it is WordPress, TYPO3, Drupal, ... at least if it gets published they will use it and question if Processwire is weak and vulnerable too. What is said here about Microsoft is probably also valid for many other great systems http://secunia.com/vulnerability-review/vendor_update.html The biggest enemy is the Third Party! 3. "In my opinion a module not being submitted to the modules directory is a sign of the author a) not knowing much of the ProcessWire environment / ecosystem (which can be a bad thing), b) not considering the module ready enough for the directory (in which case it definitely isn't ready for production use), or c) the author being too lazy or busy to submit the module (which means that the support will most likely be lacking too)." Teppo well said - but have a look to reality and you will realize that many great modules are missing but they are working. Therefore another review process should be implemented. One would be to mark modules "alpha" "beta" "stable" "obsolete" instead and having the ability to review also an alpha or beta module. 4. Right now there are only a few modules which are easily to review by one person i.e. RYAN. But when Processwire will grow there probably will be 10 times as much modules and I guess RYANs main job won't be to review all those modules. Therefore I suggest in setting up a security team, to which module developers can submit there modules for review and of course those leaks which get discovered would get reported immediately. 5. Very important is IMHO Transparency! There should be a publishing process to make vulnerabilities public as soon as they had been discovered. If the security team is working successfully they usually would be able to send a fix right the way! Yes it has to be fast - very fast actually. Which means the security team needs to communicate with the module developer - take the module off for the time the vulnerability is existing - and publishing the warning so that everyone running a site with processwire and that specific module gets informed. A Dashboard which presents that information in the Processwire backend to the customer/user would help a lot, beside this secunia is a great resource. As an example here those from other CMSs: http://typo3.org/news/security-bulletins/ https://www.drupal.org/security Publish you Policy: i.e.: http://typo3.org/teams/security/extension-security-policy/ https://www.drupal.org/security-advisory-policy and actually very good and even more important - The Security Team and review procedures: https://www.drupal.org/node/1424708 and some education to learn from: http://typo3.org/teams/security/resources/ 6. Publish vulnerabilities on secunia: - Don't hesitate and show transparency! If Processwire is secure and gets fixed right the way there is absolutely nothing to hide. http://secunia.com/community/advisories/report_vulnerability/ Please send an email to vuln@secunia.com to send us your research. Information in your report should include: Affected operating system/software, including full version details How the vulnerability can be reproduced What impact the vulnerability has on the vulnerable system Any additional details that might help in the verification process -- Check out: http://secunia.com/community/advisories/search/?search=Processwire (0) - Probably because nobody is reporting vulnerabilities! http://secunia.com/community/advisories/search/?search=modx (22) - Probably not many people are reporting or they have no one reviewing the code! no transparency http://secunia.com/community/advisories/search/?search=typo3 (202) http://secunia.com/community/advisories/search/?search=joomla (604) http://secunia.com/community/advisories/search/?search=drupal (782) http://secunia.com/community/advisories/search/?search=wordpress (1038) most important is how fast actually those vulnerabilities get fixed and how the fix is available. Often in Joomla and Wordpress you will read "edit the source etc." In more mature CMS they will provide an updatedVersion to an extension or module right the way! Compare also how many vulnerabilities have not been fixed!!! - keep some ofthose infos for your "customers" they are good arguments for marketing your solution and preferred CMS! We give our customers access to those resources mentioned above and it creates work as they want to keep their sites updated and secure! And most likely they can't do it themselves - they will realize this very fast! that this is an ongoing job which will never end! 8. Keep ALL modules also those in alpha, beta, stable and even idea state available in a centralized repository and developing space. The more people will be able to use those modules BEFORE they go into production the more testing will be done and the more feedback the developer will get, the better the module will be. This is very helpfull for developers if their modules are much easier to find and it also enables other developers to HELP and get interested. Beside that it is a nice place for checking which developers are having great coding style and which not. It would make reviews of code much much easier - and translations too. i.e. https://forge.typo3.org/ ---

The site looks nice. You still could do some great optimization. check your .htaccess check the settings about minimization of CSS / JS etc. - I guess your AIOM Settings are not sufficient or not read! check if all your images get minimized enable gzip compression etc. simply read the report and try to eliminate point by point. They have also very good explanations. Afterwards you should be able to reach values which are 90% on Pagespeed and YSlow. With the right .htaccess settings even 95% and higher. When done your site should have a loading time which would be about 1.5sec and lower I hope.

This is a good idea Nico especially also whenyou have lots of pages which use MarkupSEO. And Multilanguage is a must for modern SEO in Asia. Thanks!

Hi Teppo and Marcus thanks for having a look at it! Yes some are not compatible but often they are simply not updated ;-) to the current working version. As time goes by you will realize that also in Processwire the amount of modules and dead no more maintained modules will rapidly increase. To avoid a chaos like on other CMS I really recommend to make a rule that those not showing at least the latest stable level which woudl be 2.5 get removed to an archive. At TYPO3 that system worked pretty good after it was introduced as many Module Developers use their modules also as portfolio for their abilities etc. And immediately even Developers who did not maintain their extensions over years updated very fast to 6.2 to be again present and presented to the public. The Modules manager usually directs you to the native tools if he can't install stuff. As we tru to get the translation stuff up and running we like to have all modules and even those old ones in unless someone really don't use them anymore. But actually we will se what will get used as that will be translated the rest probably not. There are lots of admin themes which are I guess complete obsolete and if than should be removed. Keeping a repository updated working and clean with only maintained modules also helps to speed up developing and is god for the image of a CMS too.

So the en_US language folder shows 134 core and 256 module files to be translated. I have uploaded also all modules and templates and created a "modules crashing sites" folder where I have taken those modules whch crashed the site during installation or at any later point. It is mainly the templating stuff like TWIG and SPEX afaiks. I am still waiting for the confimration but actually everyone can already help to translate those files. I will see if I can create a Profile with all those modules for transtaion purposes. Let's see. Than everybuddy could help to get things done! using a local installation and than pushing the stuff to github again. or another way would be to use our translation installation (it has the multilanguage package frontend and backend.. But here I would need to see if it is possible tor restrict users to edit only their language and don't touch others. Perhaps sopmeone knows how to do that in Processwire. This way we would not need at first place weblate and could start immediately until they confirm but the downside would be that there won't be a review process. But I think if we have teams they can coordinate themselves and check by themselves as it will be mainly them afterwards who will need those translations. Right now all processwire modules which can be installed by the modulemanager have been installed and could be translated currently I am running core 2.5.10 All translations still get stored in a traditional way in assets/files on a page with PageID but I will than move those to github into the site/languages/ folderwith the correct two letter codes for language and flavour. From there everyone can pull the translations again to his site and store it where he ants ;-) until we have a better solution which first checks the files folder for a local translation and if there isn't any available than checks the languages folder and use that one. If your module is not on that github send me the link and I will install and than upload it if it installs without any problems on 2.5.10 + (always the highest version) Please keep your modules updated and working with the upcoming versions. It also would be good if the Japanese and greek Translators would shorten their package name to simply Japanese and Greek like all the other ones did already. Thanks. The files are still loading so give it some time until it will appear on git. I will let you know.

Hi as we just prepare for the translation of all processwire modules we installed all Modules and realized that some ar simply crashing the complete sites when getting installed. I will list them here and perhaps the deveolpers or somebody else who would like to maintain them can try to fix them - otherwise IMHO they should simply be removed from the ProcessWire Repository if they are already in there. If they are not in than we won't load them to be translated until it is fixed anyway. All those Modules got freshly loaded with the very useful ModulesManager! We are using Processwire 2.5.10 If you are having Problems with your ProcessWire site simply check if you have perhaps installed one of those modules! Simply deinstall them or/and move them to another location if they are crashing the site i.e. This post will be edited when we discover more problems: MODULES CRASHING SITES MobileDetect Compile Error: require_once(): Failed opening required 'lib/Mobile_Detect.php' (include_path='.:/usr/share/php:/usr/share/pear') (line 57 of /.../public_html/site/modules/MobileDetect/MobileDetect.module) This error message was shown because you are logged in as a Superuser. Error has been logged. ProcessAbbreviate Compile Error: require_once(): Failed opening required '' (include_path='.:/usr/share/php:/usr/share/pear') (line 1091 of /.../public_html/wire/core/Modules.php) This error message was shown because you are logged in as a Superuser. Error has been logged. ProcessLanguageTranslatorTwigSupport Recoverable Fatal Error: Argument 1 passed to InputfieldSelect::addOptions() must be of the type array, null given, called in /.../public_html/site/modules/ProcessLanguageTranslatorTwigSupport/ProcessLanguageTranslatorTwigSupport.module on line 180 and defined (line 72 of /.../public_html/wire/modules/Inputfield/InputfieldSelect.module) This error message was shown because you are logged in as a Superuser. Error has been logged. TemplateEngineTwig Error: Cannot redeclare class Twig_Autoloader (line 17 of /.../public_html/site/modules/TemplateEngineTwig/twig/lib/Twig/Autoloader.php) This error message was shown because you are logged in as a Superuser. Error has been logged. Spex Compile Error: require(): Failed opening required '/.../public_html/site/templates/layouts/default.php' (include_path='.:/usr/share/php:/usr/share/pear') (line 186 of /.../public_html/site/modules/Spex/Spex.module) This error message was shown because you are logged in as a Superuser. Error has been logged. TemplateTwig Error: Cannot redeclare class Twig_Autoloader (line 18 of /.../public_html/site/modules/TemplateTwig/TemplateTwig/Twig/Autoloader.php) This error message was shown because you are logged in as a Superuser. Error has been logged. ProcessLatestComments Error: Class 'Comment' not found (line 59 of /.../public_html/site/modules/ProcessLatestComments/ProcessLatestComments.module) This error message was shown because you are logged in as a Superuser. Error has been logged. MODULES NOT SHOWING AS INSTALLED even they have been installed! FrontendUserRegistration LdapSignIn TextboxList MetroWire EleganceAdminTheme Compliance FrontendUserProfile SmartyTemplating TextformatterAutoParagraph Unify Teflon WireTasks BootstrapAdminTheme AppyAdminTheme FuturaAdminTheme ErgoAdminTemplate MODULES NOT SHOWING AS UPDATED AFTER AN UPDATE FlagPages ProcessJSONInstaller LanguageLocalizedURL MODULES CRASHING THE TRANSLATION TOOL INSIDE PROCESSWIRE UserGroupsHooks NOT USEFUL MODULES FOR TRANSLATIONS ProcessLanguageTranslatorTwigSupport --> It is radically deletes the ProcessLanguageTranslator Page when you dseinstall it and it does not offer multiple file select to be translated. If you have more than 10 files to be translated this means 10 times the same clicky click procedure every time until all 10 files are able to be translated - it wastes a lot of time! OTHER PROBLEMS WHEN INSTALLING MODULES VersionControlForTextFields --> snapshot module seems to be doubled - why not simply checking and deinstalling the one which is to much instead of bringing up that error. Warning: there appear to be two copies of module "PageSnapshot" on the file system. Please remove the one in /site/modules/ unless you need them both present for some reason. 1. /site/modules/VersionControl/PageSnapshot.module2. /site/modules/VersionControlForTextFields/PageSnapshot.moduleMarkupLoremIpsum--> Why does it want to deinstall when we want to install?Could not remove directory /.../public_html/site/assets/MarkupLoremIpsum.module TextformatterSoundcloudEmbed --> Path wrong FuturaRemixed CustomPageRoles -->Could not open zip file ServicePages --> Displaying the code of the site in the frontend! CryptoPPP --> not able to be installed and therefore many other modules which depend on that cryptoPPP are simply not installable and not working

I am just loading all available translations and realized that there is also a naming inconsitency which should be standardized throughout Processwire. 1. two letter code for language (small letters) underscore two letter code flavour (capital letters) Right now the easy language install mdule shows on the add page the correct way in fdoing it but than on the installed languages both parts are in small letters only which is not consistent and confusing! Also German exists twice as de and as de_DE and finnish is only fi too! On https://github.com/PW4ALL/ProcessWire-Weblate/tree/master/site/languages it is all now standardized. the languages are right now just uploading. I assume that this is right now only the translations of the core. Name Title Core Translation Files Site Translation Files default English 0 0 de German 119 2 fi Finnish 0 2 zh-cn Chinese 84 0 cs-cz Czech 99 0 de-de German 122 0 es-es Spanish 25 0 fr-fr French 67 0 vi-vn Vietnamese 70 0 he-he Hebrew 36 0 it-it Italian 38 0 ja-jp Japanese Language Pack 70 0 hu-hu Hungarian 135 0 nl-nl Dutch 24 0 pl-pl Polish 37 0 pt-pt Portuguese 20 0 re-gr Processwire-greek-language 20 0 ru-ru Russian 68 0 sk-sk Slovak 37 0 se-se Swedish 23 0 tr-tr Turkish 135 0 also here the naming is quite inconsitent http://modules.processwire.com/categories/language-pack/ and should be corrected (actually those would no more be needed) if weblate will be used for future centralized translations. Or better would be to simply update them than from the translation git. Spanish exists even doubled with same name! es_ES which is not usable and confusing! Turkish has exactly the same problem and is existing twice. Collaboration would avoid it and marking a flavour with a different 2 letter Flavo code woudl help to clarify what s actually needed and what not! If there are more translation files of the core please let me know so I will add them to https://github.com/PW4ALL/ProcessWire-Weblate/tree/master/site/languages. Thanks

As I wrote I took the German Translation as it seems quite good and complete (most translated) You can find it here: https://github.com/PW4ALL/ProcessWire-Weblate/tree/master/site/languages as there are no English JSON files we woudl need to create them like a normal translation like I wrote above. Concerning using a PageID or using a PageName this can be a very little change IMHO. Instead of the ID we would choose the pagetitle ;-) and this would be than de_DE instead pf PageID 1012 and fi_FI instead of PageID 1013 in my Example I described above. For older sites there could be even a fallback like: Choose the Page Title if available, otherwise choose the PageID To keep things much clearer as they are right now I moved all translations into the first "site" level = site/languages/de_DE/.....json file Like in WordPress and in TYPO3 wie would use a separate language folder. (also this change for the langue files is actually only a path which would need to be changed in Processwire - so it is not a big deal. Also here could be a simple question in the next releases asking what folders should be used: site/assets/files/1013/.....json or site/languages/de_DE/.....json. and as you wrote already in Version 4.0 or perhaps already in 3.0 this could be changed to site/languages/de_DE/....json as default and people still would be able to do itthe old way by checking the fallback (old) solution. Usually if things work fine and things get translated on the server many more people will start using and finally use only the translations from weblate. As we don't change the naming of the json file itself actually all those translations could be simply been pulled from github for everybody and than inserted in a very traditional way too without any further changes. ;-) To update all those translation files and also to aff all those translation files which are currently already available I will extend our transaltion processwire site so that we can install here all available modules. We can use it also to see which nes get updated and which not. A cronjob will than regularly update this site and also copy the language.json files. If you have an idea what would be best to assure that the already translated translations get not overwritten by updating the modules peobably with anolder JSON file, please let me know. Scenario: we install a module in the site and have the site translated into another language, which means there is a translaotion.json file probably available for that module already. Some time later we update this module and again the translation probably gets updated (and is probably overwriting the old one grrr). IMHO we should move a module translation only once to the translation server and everything later has to be pulled from the translation server! After we have moved actually all cor and available module files to the weblate this will be a one stop solution as people will simply use it as it will provide much better translations for much less effort as it is community driven ;-) But OK we simply need to start it to get everything up to weblate as fast as possible. I will look in that next week and upload and update all I can get on translations in German. I use German as it has already a great community like many other Open Source CMS and I am German and can understand it ;-) In parallel you could start looking after the russian stuff too and add more translations. As I pointed out already ru_RU would not change the filenames in that folder and therefore could be easily uploaded to the site. We could even modify the easyinstalllanguage Module in pulling the languages from the pw4all/ProcessWire-Weblate repository.

Great idea! This is the place we intend to collect all modules. We got already the core in - ok we need to manage the updates later on a regular base. https://github.com/pw4all Have a look to https://github.com/PW4ALL/ProcessWire/tree/master/site-languages/install/files Here the translations for German and Finnish got stored in 1012 and 1013 while the German folder contains lots of translated modules already and the Finnish one only 2 translations actually. The way those translations get stored and the folder name is actually not really a good way doing it. Better would be to name the German Folder de_DE, or de_CH, or de_AT as depending on the region you are there are differences in the translations and would need to be reflected in a site translation or the one of the modules. The same actually applies to en_US, en_CA, en_UK, en_AU etc which are all not the same even most words probably are the same or similar. Another source of actual problems is the original text as this does not get stored in a json file! let's talk about an example: go here: https://github.com/PW4ALL/ProcessWire/blob/master/site-languages/templates/_main.php you can see the original text parts as they look like: No 1 - echo _x('en', 'HTML language code') No 2 - __('Edit') No 3 - echo _x('Search', 'placeholder') No 4 - echo _x('Search', 'button') No 5 - echo __('Powered by ProcessWire CMS') No 6 - sprintf(__('Logout (%s)') No 7 - __('Admin Login') and compare it with the German translation: https://github.com/PW4ALL/ProcessWire/blob/master/site-languages/install/files/1012/site--templates--_main-php.jso { "file": "site\/templates\/_main.php", "textdomain": "site--templates--_main-php", "translations": { "6f9fc985da145fcdd180f254dd161c57": { "text": "Suche" --- echo _x('Search', 'placeholder') -> No 3 }, "2c889b7622e6ed4e56a1414ac333c814": { "text": "Suche" --- echo _x('Search', 'button') -> No 4 }, "7dce122004969d56ae2e0245cb754d35": { "text": "Bearbeiten" --- __('Edit') -> No 2 }, "3ee693d376f73e2bfa34e985c30bec66": { "text": "Abmelden (%s)" --- sprintf(__('Logout (%s)') -> No 5 }, "b6e31daf2404aab3d78c7e972dfe3f8d": { "text": "Login" --- __('Admin Login') -> No 6 }, "7679c0bdbd87c1984bd611c24b3cd0cb": { "text": "de" --- echo _x('en', 'HTML language code') -> in Head Section No 1 } } } No 7 is missing in the German translation! and with the one of the Finish translation: { "file": "site\/templates\/_main.php", "textdomain": "site--templates--_main-php", "translations": { "7dce122004969d56ae2e0245cb754d35": { "text": "Muokkaa" --- No 2 }, "91e2c8e591043b9d9c7611a185358068": { "text": "Toimii ProcessWire CMS" --- No 7 }, "3ee693d376f73e2bfa34e985c30bec66": { "text": "Kirjaudu ulos (%s)" --- No 5 }, "b6e31daf2404aab3d78c7e972dfe3f8d": { "text": "Kirjaudu" --- No 6 }, "6f9fc985da145fcdd180f254dd161c57": { "text": "Haku" --- No 3 }, "2c889b7622e6ed4e56a1414ac333c814": { "text": "Haku" --- No 4 }, "7679c0bdbd87c1984bd611c24b3cd0cb": { "text": "fi" --- No 1 } } } as you can very easy see there is abolute no logical order in those translation files. Similar to PO files the translations are assigned to a certain string. Without an external tool actually or an integrated solution translation is a hazzle like this. only as a comparison to that here a file from WordPress, where you can see a very clear structure and order but also here you need to translate stuff in an external program which creates the right matches so it will work with your templates. #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:16 msgid "Page not found" msgstr "" #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:20 msgid "" "We're sorry. Your page could not be found, But you can check our latest " "listings & articles" msgstr "" #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:24 msgid "Latest Listings" msgstr "" #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:44 msgid "Latest Articles" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:452 #: wordpress\residence\!versions\1.07/wpresidence/templates/search_unit.php:19 msgid "Search Parameters: " msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:458 msgid "Save this Search?" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:459 msgid "Search name" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:460 msgid "Save Search" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:472 msgid "" "Login to save search and and you will receive an email notification when new " "properties matching your search will be published." msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:506 #: wordpress\residence\!versions\1.07/wpresidence/search.php:32 msgid "" "We didn't find any results. Please try again with different search " "parameters. " msgstr "" Wordpress always needs an aditional mo file! Þ•$,8˜9Project-Id-Version: wpresidence POT-Creation-Date: 2014-11-17 10:56+0200 PO-Revision-Date: 2014-11-17 10:56+0200 Last-Translator: Language-Team: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Poedit 1.5.4 X-Poedit-KeywordsList: _;gettext;gettext_noop;_e;__ X-Poedit-Basepath: . X-Poedit-SearchPath-0: E:\!our theme wordpress\residence\!versions\1.07 and TYPO3: you can very easily edit the xml file in any editor if you like! <?xml version="1.0" encoding="UTF-8"?> <T3locallangExt> <data type="array"> <languageKey index="de" type="array"> <label index="mlang_labels_tablabel">Informationen über Module</label> <label index="mlang_labels_tabdescr">Zeigt diese Seite über die vorhandenen Module an.</label> <label index="mlang_tabs_tab">Über Module</label> </languageKey> </data> </T3locallangExt> TYPO3 translations always hava ow also the xliff file <?xml version='1.0' encoding='utf-8'?> <xliff version="1.0"> <file source-language="en" datatype="plaintext" original="messages" date="2011-10-17T20:22:32Z" product-name="aboutmodules" target-language="de"> <header/> <body> <trans-unit id="mlang_labels_tablabel" xml:space="preserve" approved="yes"> <source>Information about modules</source> <target state="translated">Informationen über Module</target></trans-unit> <trans-unit id="mlang_labels_tabdescr" xml:space="preserve" approved="yes"> <source>Shows this page about available modules.</source> <target state="translated">Zeigt diese Seite über die vorhandenen Module an.</target></trans-unit> <trans-unit id="mlang_tabs_tab" xml:space="preserve" approved="yes"> <source>About Modules</source> <target state="translated">Über Module</target></trans-unit> </body> </file> </xliff> Go and compare also the folder structres and where those translations get stored and you will realize that it is very easy in TYPO3 - typo3conf/l10m/de/modulename/mod/de_locallan_mod.xml especially also because each module has the original translation already in an xml file available (same format!) They work with placeholder texts! a bit more complicated to find in Wordpress - wp-content/themes/themename/languages/themname.po - allways depending on a theme and actually quite complicated in Processwire as even the location changes during the installation process from site/install/files to site/assets/files site/assets/files/1012/site-templates--_main-php.json and than even in another language the files have the same name! site/assets/files/1013/site-templates--_main-php.json without having a look inside one of those files you even don't know what language they are! ---- while you have in WordPress and in TYPO3 the original language or the placeholder name ALWAYS available in a readable form it makes it way easier to translate. ==================== My suggestion rightnow would be to ask Ryan for a clear statement on how the translation is actually done in TYPO3 so that we can figure out a feasible way to get all the originals into the translation system. Right now this system is actually ONLY working if people stay brave in English in their originals which limits Processwire already and lowers probably even it's quality as people are more or less forced to use probably a language they can only translate via Google and to be honest - Google is nice for public usage but not at all suitable for a professional translation. Questions to people who did the translation module of processwire and Ryan. 1. What would be the best way to pull out the translations in the original file? What format as the original is stored in php files and not in json files unfortunately 2. How can those location strings be generated and assigned? 3. Would there be a chance to change the way / file formats, translations get done. Probably we don't even need a big change as IMHO only a Json file with the original Language would be needed ;-) Benefit of this idea: Processwire would NOT depend on any default language and could set any language as default and define even a very flexible fallback of languages. In other words. All original languages which have been already been inserted into processwire .php files would beed to get extracted to a json file which is in English language. As there are different flavours of languages which are quite important when selling websites, the numbering need to be changed and I suggest to use de_DE, en_US, de_CH, de_AT, en_UK etc instead. Many English, German or any other Language flavours would be possible after that change. After the complete extraction of those language translation terms inside the defaul PHP files to jSON files those default PHP files could also hold also simple placeholders instead of the original translations. This would make it for non English spoken Developers much easier to contribute. They would set a "marker" and than add their localisaztion which could be german, russian and thai etc and the english one would simply be missing until somebody comes and is able to translate it into english language. If a separate JSON file in english would be available than also the problem with setting a default language would be solved very easily. I think there should be a way to parse all .php files for __ _x _n and extract all those terms into one external json file per .php file. It would use a standardised labeling - i.e. en_US-locallang-modulename.json in another step we can collect all those en_US-locallang-....json files and put them in a centralized folder i.e. files! I personally would avoid using files for that purpose as keeping all translations in a translation folder or simply call it "languages" would be much much easier. As than those files are in another location and also there woudl be now an original english language file which itself could be translated into several english flavours, only the paths to those newly created languages and localisationfiles would need to be changed. the structure at the end would look like this site/languages/default/default-locallang-module1name.json site/languages/default/default-locallang-module2name.json site/languages/default/default-locallang-module3name.json ... site/languages/en_US/en_US-locallang-module1name.json site/languages/en_US/en_US-locallang-module2name.json site/languages/en_US/en_US-locallang-module3name.json ... site/languages/en_GB/en_GB-locallang-module1name.json site/languages/en_GB/en_GB-locallang-module2name.json site/languages/en_GB/en_GB-locallang-module3name.json ... site/languages/de_DE/de_DE-locallang-module1name.json site/languages/de_DE/de_DE-locallang-module2name.json site/languages/de_DE/de_DE-locallang-module3name.json ... site/languages/de_CH/de_CH-locallang-module1name.json site/languages/de_CH/de_CH-locallang-module2name.json site/languages/de_CH/de_CH-locallang-module3name.json ... now it would be very easy to pull ONLY the files from site/assets/languages/*/*.json into weblate and translate them. As Json files are monolingual we woudl need to define a default and this could be the default folder (even it would be a duplicate of any other language, but this folder would simply hold all "placeholder" strings which could be in English or German or simple placeholders. This site/languages folder could regularly check with the core and all modules i.e. on pw4all github if there are any new strings which would need to be translated. It would update the default files but all language files woudl stay the same. Those strings which are i.e. missing in default now would be marked as to be deleted in the translation files (but carefull as perhaps some older modules from people who don't update their sites would need them) and newly added translations would be marked as new and to be translated. This way a quite fast workflow could be created to get translations up and running very fast as a community based effort using weblate. site/docs/default/default_doc_module1name site/docs/default/default_doc_module2name site/docs/default/default_doc_module3name .. site/docs/en_US/en_US_doc_module1name site/docs/enUS/en_US_doc_module2name site/docs/en_US/en_US_doc_module3name ... Concerning the documentation I suggest to do actually exactly the same like with the languages and use readthedocs for the default and present alo the translations on readthedocs. also this documentation gets stored on github in a documentation folder which simply lists the modules. Each read the docs file could than be pulled if needed in a site from there. ----- But the first step would be to get Ryan involved here as if the core won't provide a base json file it is a bit crappy to translate the rest! - there really needs to bea better logical order and structure in folder/ file-namings and inside the translation .json file itself. ---- So the first step is done but I need to wait now until those files will appear. I took a site we use for our purposes and it has nearly all modules already translated into german language ;-) That's fine. I created on a new repository in where we will store all those translation files. I already changed the folder namings to be de_DE, fi_FI like it should be. Next I will try to ecxxtract all the English stuff as there is no JSON file available right now but irt would be very usefull. I will let you know as soon as we get further on weblate and than see how to continue. If you can see a way how to extract all the english defaults into one JSON file this would be very appreciated! We now continue also setting up the docs on readthedocs People who want to join this effort please contact us via PM so we can start creating translation and documentation teams. --- You are right Ivan that it is a lot to read but IMHO it is worth it and we need people who like to contribute so they need to know the idea behind it. Concerning Ryan you are also right that he is probably busy with other stuff and that is why we already started right the way. But I hope that he can at least get his thoughts on how to extract the default translations and how to probably change the page numbering 1012 to a de_DE etc. I guess that this won't be a big deal. If you have ideas please contribute them here as I am sure people will read and follow the thread.

Hi Jtherczeg Transiflex is not really FreeOpenSourceSoftware (Free = Freedom) and it unfortunately also not Free (Free = like Free Beer). Readthedocs woudl be connected already to Transiflex by the way but I think with weblate we can do the same as they themselve use Readthedocs for their own documentation. Weblate does support translation of monolingual resources like JSON. http://docs.weblate.org/en/weblate-1.7/admin.html (scrol down also for finegrained access rights - it is really great with weblate! "You enter Git repository location and file mask which files to translate and Weblate automatically fetches the Git and finds all matching translatable files." The initial problem is actually only to get all language files into the right order - into a logical one into the repository. Right now we choose the structure to have a translation for the core in one gitbranch and the modules in another - we need to test out what is best way doing it! As we aourself ned to use also modules which are NOT in the priocesswire repository and those which are simply in a non stable state but used already, we will try to collect all modules to that repository and update it regularly via scripts which git pull from the original repos. The problem here is that with a git pull also the translations would be overwritten. So much better would be actually to have a centralized repositopry also for development where all modules could be than continously be updated. Another problem we already figured out is that the processwire repository seem s not to be maintained in terms of looking for modules which get no more maintained at all by their module owners/creators. This is causing a buit a chaos of modules which than even won't update anymore correctly. We have here one site where wesimply install all those modules in and than when one get updated in the processwire repository the great modulemanager module will alarm us that an update is available. Doing the update than with thos no more maintained modules results sometimes than in incorrect updates or incorrect notifications (versions) that the update actually took already place. We contacted some of the module owners and some are fizing it and others are simply no more with Processwire ;-). This might cause also problems for the translations but we will see! You are right mediawiki could be used immediately when it woudl get installed on a server. Which server - the one of processwire.org Who is maintaining the server Who will have access with what rights Who is taking care for the wiki itself ... and I guess some more questions which are more or less obsolete by using readthedocs ;-) Beside this each individual could create his own readthedocs account for their custom documentation and than pull that custom documentation they write for THEIR individual customers into multiple site of them. The problem with Mediawiki or also with Pootle is that 1st this server needs to be maintained by someone and MediaWiki and it wuld be the same if using Pootle itself needs to be maintained by someone beside the fakt that we would need someone managing theaccess stuff which would also be needed on any other solution. Wit Readthedocs we would have no problems at all with their Server (Cloud), or with the Software Readthedocs is using. The maintenance Footprint is very very small by using Readthedocs. And the docs look really good! Check it out. Media Wiki and Readthedocs would be by the way both external solutions as the documentation will take place outside of processwire. Than the needed docs - and only those needed by the modules/core and by the installed translations should get pulled into a Processwire installation and updated regularly like we update modules already in processwire. Beside that there should be the possibility to modify locally an translation which than gets not overwritten anymore by the updates of a modules-language file. Here by the way the way Macura is writing the docs inside of Processwire could be quite helpful. we only would need to pull the original translation i.e. via RSS and than i.e. could overwrite them in another tab on a page. Each module which gets installed would also install their documentation page in the admin area, which would than incllude this feed and the local Tab - with the customized translation. The tabs itself for each module than would need to be able to be enabled (default) or disabled i.e. when there is a complete customized version or both enbled when thereis simply additional information a dev is writing for a customized site. Another great benefit of weblate would be that everyone can actually install a local version of it to for himself. It is real Free Software. The same way you can install readthedocs locally and you can of course have also your own git - in other words you can collaborate butit woudl offer you all choices actually to also not collaborate totaly or in parts without loosing the ability to pull docs from the centralized solutions. Of course the maintenance effort would be than by each one self who is maintinainng his own local servers with weblate, readthedocs and/or git ;-)