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 ;-)

Hi Beluga Your idea is also a possible way. We actually use it at TYPO3 to document errors and write some additional documentation but we think our suggested solution would be the better choice. Often in threads about translations or translation servers it was talked about the amount of time needed to maintain and fix the system itself. This will be always the case with selfhosted solutions. Therefore we are currently following the idea to pull the core and modules on a separate github account where it would be easier to collect also all those modules which are not available in the processwire repository right now. Translations could actually already start in a muchearlier stage than a stable release IMHO. This will be connected to weblate and readthedocs. This way we will be able to write documentation on readthedocs and to do the translation part of the modules on weblate. Weblate is supposed to be able to handle json files, which are actually monolingual files. As nobody from the Processwire community had to worry about the weblate or readthe doc or github server we would only need to get all the docs and files to be translated to weblate. If we have figured out the best way in doing that this process could be automated by a script we think on a daily or even half daily base. well said Ivan, you are absolutely right! Thanks Andi

Version 2.3.0 Installed? 2.2.2 This is themessage we get after we ran the upgrade to Version 2.3.0? The BlogInstallWizard.php shows * @author Kongondo * @version 2.3.0 Andi

Hi Apeisa I started a new topic as this discussion in the older thread was about finding files on Mac! You can find it here: https://processwire.com/talk/topic/8389-centralized-translation-of-processwire-and-pw-documentations/ There only a globallised solution should be discussed. Nothing else. We for us have made the decision already, as we work on multiple projects and we are now looking only on the best globalized way in doing the collaboration part. We simply can't wait until translations and documentations get done in a collaborative way, also because our devs and customers both are spread all over the world ;-)

This Thread is opened new as it will only discuss a centralized solution! nothing more and nothing less! The quotes are coming from the former Thread which was actualy about finding Language files on Mac and had nothing to do with the actual problem of PW! In Processwire there are 2 major problems with translations when working especially with Multidomain sites in one processwire DB 1. The default can not be defined on a per site base like in other CMS with Multidomain support in one DB. i.e. the default language get's defined by the guest user but this guest user is existing only once! You can't define a guest user on a per Domain Base in a multidomain installation which is working with one DB. Solution: Instead of defining the default language by the language of the guest user it woudl be advised to have some code or dropdown or whatshowever to choose the right default language on a per site base. This can happen i.e. through code inserted in a specific site template belonging to one domain. 2. Working with translations in Processwire is a hazzle - really and it could be much much easier. We are just testing it if Weblate or Pootle could do the job and the same with the documentation to probably use readthedocs / sphinx instead. To reduce workload on the developer site and also to increase the quality of documentation and translations it is very important to be able to collaborate with others on this. Therefor a local solution (in a module or elsewhere locally) can never be the right way in terms of smoothness, economie and workflow. As we need at least 2 - 3 translations in nearly every site we are working with including the translation of documentation (especially those for editors and site admins) we will work on a solution which lateron might help to solve the problems of all. I only hope that the modules don't get cluttered up with lots of localized files now. - If this would habben than each module we are using here will have soon also translations of Thai, Khmer, Laos, Burmese, etc in it and for sure nobody in Europe would need them! Keeping things centralized on a centralized system is the much much better way for translations and documentations. This is the case if you need to run all churches from their own DB as some have german, some English, some Thai, some even Arabic as default language! And for sure we won't handle such an amount maintaining all those translations - that's why the churches would need to handle their stuff all by them selves which will end up in a chaos and finally in a no go command from those churches to use Processwire! Most of those Churches work with volunteers and are not those Mega Million Churches with Cathedrales etc. like you see often in the US. They have usually a dedicated webteam, but ours are very tiny units and need to keep costs at anabsolut minimum. The same applies to the multidomain School Servers with many school/classroom websites in them etc. 90% of them would need another default language than English and the default languages are changing depending on the location where they are. Well as pointed out above it will be a real hazzle to keep the quality of translations and the standards if there is no centralized solution in doing all the translating stuff. Updating a translation can happen by a module and should happen by a module - no question! - But instead of storing all translations inside a module it would be adviced to keep them separated and store only one language (the default language of the module - which could also be German or even Thai) inside the module. The module in the backend would than check with the translation server which new translations would be available and download those tranalations ONLY for those modules you have installed. Those translations than get storred in a separate directory where wll those translations can be managed or even be overwritten partly by a second local translation folder for only local translations. With a fall back methode it gets checked which translation is available and should be used. is the translation available in the folder for local translation yes no? If no than check in the global translation folder yes no? If no download it from the language server? yes always means = use it. And the update process would be similar but simply skipping the local translation folder. This way you can ensure that modules always have accurate and updated translations. Finally you might run that process than via a cronjob or manually - up to you! --- Translations itself will be done on Weblate or Pootle and docs (so our idea on readthedocs or a global sphinx) Module editor provides the default language (which could be any - but the language would be needed to be specified by a code - i.e. en_UK, de_CH, de_DE etc. A parser will parse the modules directory for those default language file and convert the json into mo/po for use in Pootle. With Weblate we could integrate json directly On Weblate/Pootle those files can be translated in a collaborative effort, even by none developers, but i.e. by people who are good in translating stuff - this keeps the quality high and it will reduce the workload on developer sites as they don't need to worry about the translations or even don't have to integrate them into their modules etc. Now an integrator sets up a website and defines the default and other languages. A module will now check if there are new translations available for the installed languages and they can be downloaded and stored in the site like described already above. -- Maintenance Tasks would be quite low on the site of the Weblate/Pootle Server site. The benefit of Weblate would be that they have a FREE hosted Version of webslate of OpenSource Projects - so no maintenance stuff would on PW site concerning the translation server which is great. (but we would need to change some stuff - see below) Readthedocs is very well maintained already and it is completely free! An ideal way to do documentations and meanwhile used by lots of projects and parts of projects. And of course the module which will manage the translations needs to be maintained to so that it will continue working when the core gets updated. But this would be the case anyway with any module ;-). But here we would need to manage the connection to weblate/pootle. But also here the hosted webslate solution would be the best way to go as it can parse github repos and the translations of readthedocs will be actually hosted on a github ;-) In other words it will simply work. using Pootle it woudl be a little bit more work as the Pootle server would need to be maintained as pointed out already. -- Extendibility of that idea: 1. Integrating a backend part to translate / propose translations from within PW 2. Doing the translation of strings with a local application (which than will store those localized translations in the folder for local translations, like described above.) This can already be done by a module and this module only would need to be adjusted (enhanced) to work with translatins coming from the central langauge repository. -- WEBLATE - READTHEDOCS - GITHUB We discussed it here in our Team and we think that it is the best way to go! If there are any other ideas let us know - but for sure we are not interested in a solution which will clutter up module and corefiles with all kind of translations/documentations which we won't use on our sites! And it must be a solution which allows collaboration with others to reduce workload. Readthedocs can work with transiflex but until now we can't see a better free solution than weblate or pootle http://www.oneskyapp.com/comparison/transifex-alternative/ Some links for those interested: Readthedocs (maintained and hosted) https://readthedocs.org/ Weblate (maintained and hosted) http://weblate.org https://hosted.weblate.org/ http://weblate.org/en/features/ http://weblate.org/en/hosting/ Pootle (selfhosted) http://pootle.translatehouse.org/ We propose the following way to go IMHO https://hosted.weblate.org/ + https://readthedocs.org/ + https://github.com/ Benefits: We could reuse the JSON Collaboration on translations would be available Documentation would be available for translation to The code gets already maintained on github while I suggest to open up another repo in which all modules (also those not approved meanwhile by the ryan team) could be integrated for translation and documentation. This would help to get translations and documentations done already in an earlier state than stable. If you know a better maintained and free solution like we proposed above to be used for a collaboartive translation and documentation effort, please point it out and describe the benefits of it in comparison to what we propose here. --- Important REMARK: This thread is NOT meant to discuss if there should be a centralized or only a local solution! Please keep all stuff concerning this out of that Thread and discuss it elsewhere. This Thread here is ONLY! about a globalized collaborative solution where the translations get managed at a centralized place and where documentation gets written on a centraliced place and where we create a module to integrate all those translations and documentations. Who would be interested to work with us on getting things done and to move the modules and documentation to weblate and readthedocs. PM us! Thanks.

And because it is such specific it belongs into a custom module and not as something which shoudl go into modules or core! Otherwise those things get bloated up as you said LostKobraKai. Nevertheless would need also such a custom module a way to translate those docs1 Everything what has to be installed locally especially for devs is causing more work for devs. Better would be to have those gerenal stuff available on a centralized server incl translations where everyone can collaborate with others and share their translations. Than if a dev needs a customized version he can i.e. download the specific part and customize it even in the translations. Who says that you don't have the proper control? You as an Processwire Integrator are developing a site for a customer the same as I deveolp one. We both have same but also different modules installed now those modules can read the files incl. their translations from the centralised version where the extension developers and translators i.e. me for thai or german would collaborate. Or a devwho is not so good in English provides a great German docu und you (if you can understand german) or anybody else could translate it into english so that people who can't understand german would understand it. Now you have the option - either you take the doc as is or you overwrite the stuff you want to present to the customer, which means you create a localized version wich fits only your very specific site needs. Of course it will be your time and effort to modify it - incl the translations, but if the centralized docs are very well structured than it is very easy actually to pull out the necessary stuff even from the translations which would safe other developers even when they want to create a localized version a lot of time. Reiniventing wheels is never a good solution and the centralized repository with those general docs which can be downloaded locally is much easier to maintain than any local version of docs which only blow up the stuff. At the end it would be the decision of the INtegrator to use the provided General Version incl their translations which are available - getting them directly without blowing up sites, or loading the customized version of a doc which would blow up only your site of the customer. Inspire to share! should be the motto instead! and it would reduce costs for everyone working with Processwire a lot! especially when they need a translation into another language than English! - Collaboration is the way to go IMHO!

Hi Joss this was actually what I was talking about at first place. The customers are not so different I think. You actually will have 4 kind of customers - from our experience. I mentioned them already above. All of them have their own specific needs in what they want to learn about the system. Developers: They are interested in the code, settings, configuration options, on how to extend a certain module etc - as we do outsourcing here to this is one kind of clientel we are having Designers: They are less interested in the coding but much more in how they can design a template with that module. They often need to know about configuration settings but usually won't code in the core of a module. Admins: This is actually a group which every site has as they need to maintain a site. I know that many agencies don't care so much about maintenance and security after they delivered a site. Well we are for sure different here as we care a lot about it to make our customers happy with a site for a long time. So we teach an admin how to check for security updates and if he can't do the upgrade by himself - well than he cancontact us or another developer. Also all information about how to create users, groups, roles and access rights etc belongs into that section as well as how to make a backup of a site. Editors: They are the ones you are probably talking about. They usually don't need to know much about the functionailty of a module - in terms of configuration, coding, design or administration, but they need to know in how to make usage of a certain module. This is why the Tutorials and Manuals for Editors will look very different from all the others. They usually contain screenshots to make it easier for them to follow the tutorials. We here have all 4 kind of clients and there is also a 5th Group which actually are all those "site self builders - but they more or less can read in all 4 sections. Nevertheless is an integrated solution where you have to upload your stuff to a certain site a huge ballast, which will make the sites or even the core or modules unnecessarily big. Therefore the much better solution is actually to keep those manuals centralized as I pointed out already with the huge benefits you will gain by doing that. All our Editors until now (since 2002) wanted to have their Manuals in their language! and this was in 90% of the cases not in English! Even the Admin Manuals had to be translated - especially for German and Thai spoken customers. Having an online solution where everyone can contribute, this is an easy task, while writing all the stuff by your self over and over again, without the chance to update it regularly is a huge hazzle. You are talking about modules and even core functionallity which is somekind different about what Pete was talking. While you talk about general information he was writing of specific stuff. Both are different kind of stuff with different needs. In what language you will provide that information? English? How do you translate that information to make it accessible for people which don't understand or can read english? Like said with an centralized online solution this is very very easy to handle! Let's take our Thai customers as an example: They want to know what that Hanna thingy is and click a button and have an english explanation what they hardly (mostly not at all) can understand. So where do those people getthe translation of that what you provide for the Hanna Thingy? This actually sounds more like a small question beside a certain field with additional information for that field. We have something like that also in TYPO3 and to be honest most customers don't use it! But on the other hand it is able to be localized. As itis information provided to a module that information will be always the same for all people using that specific module and therefore a global approach where you can contribute a translation i.e. to Thai Language or German Language etc, will help all other developers to which are using that module. - Check out the Poodle discussion on how to do it! That's why things like you propose here should go into a module which people who need an English and not other Language Explanation can install it or not. The same way the other option I propose would go into a module to not blowing up the core of processwire or the modules itself. Of course they want to have it accessible from within their backend. That is also what we do in other systems to inform customers about functionailty and other information just from within the backend. They actually not even know that the information gets maintained centralized. Those who have an Intranet solution with no web access can integrate an offline documentation. The most important part I see in all of this is in how you will handle the translations and the updates of those documents! Perhaps you can explain that a bit more! For whom should this documentation be? - I think it will be Endusers of a site - which means Editors - am I right, perhaps admins? Who is supposed to write the base documentation? - I guess the developers In what language should they write their documentation for those Editors? - I guess in English, even he has only German customers. No English customers he/she will write in German I guess! Who will handle the translations of those informations? Where will be those informations be handled/stored? - Inside the core and inside the modules I guess which will blow them up! How do you handle updates which come with modules - i.e. a Blog Module or SEO module comes with additional features? How gets the translations of those updated modules get stored and handled? It would be nice if you could explain how a German or Thai Enduser with no or limited English Knowledge make usage of it! Where does all that base information gets stored? - I mean the original "English" or "German" Version

Well if it is such specific I would put it in a module as such kind of documentation usually goes into a print out manual or PDF and not at all needs to be included into the admin area. It blows up the site unecessarily and makes it heavy especially when you add screenshots images etc. Like you said if it is such specific keep it specific for those who don't write manuals as pdf for their customers. IMHO much more important is the general usage of a processwire site and this can be managed very easily like I described above and it does not blow up the sites with unnecessary ballast. It gets loaded from a central server includes translatations and would make the job for devs and manual writers much easier. Beside that a great documentation about the possibilities of Processwire categories for the 4 Group of users would be available - similar to a good book! With the "sepcialized" doumentation you woul do good to keep it on your server and connect it to that as described. So you can make changes and improvements to the doumentation whithout the need to access sites and usually there are many things you simply could reuse on most of your sites. With taging you could put them into an order. Beside that it would be also a great place to inform customers about news, security fixes, improvements, or even special offers as you could add them on your server. This could drive also more revenue to your business! and to Processwire!

hmm Joss - What should be the purpose as all this site specific stuff would need to be created over and over again, unless you duplicate a site profile which already includes the docs. In our experience most of the stuff especially editors would need can get covered by extension/module/app documentation which is in a standardised format and which can be included into the sites depending on what modules got installed. The thing you propose here seems to be a whole lot of work as no collaboration would be possible and it had been mentioned already in many threads that developers have other preferences than writing docs or wasting time with that stuff, and they are right. Actually you could include some specific stuff still into the doc. i.e. The site is calling an iFrame with the docs in the backend or the frontend or it is pulling an rss depending on what modules got installed. Beside that the already integrated notes do a great job IMHO but you could also include another nicer looking doc with images again i.e. from YOUR server so that at least you could reduce your own workload in writing those docs while you won't be able at all to collaborate with others or get help in Translations of thedocs. Don't underestimate Translations - its a whole lot of work and Editors often don't speak English or German and site owners usually like to have their docs in their languages. With a centralized online solution this is easy to accomplish as you can collaborate with people from all around the world.

Ok thats exactly what is needed great!

Doing Documentation is not an easy thing and there shold be standards so that all those docs don't look cluttered all over. If you have time have alook how it is done in TYPO3. Here the extension developer provided and OpenOffice This works pretty good as you can list those documents in thebackend if needed. The docs itself have standardized sections so that you immediately know if it is for setting up , maintaining, or editing stuff etc and it includes a reference with all possible settings. As a developer you usually have a look to those docs but not as an editor as they contain the technical stuff too and people who are editors get shocked. So first you need to clear out for whom you will need docs. Editors Admins Developers Designers Than you should use a methode which is easy to handle for developers to, as usually developers which can write good understandable documentations for admins and editors are very very rare. Than you need to think about the ballast of a documentatin which is integrated and where actually nobody can contribute. So IMHO the much much better solution with much less ballast for core and modules whould be to keep those docs external on a centralized server where everyone can contribute and write, auggest, review and this place you link with a module to the backend of processwire - or even to the frontend. Now you can categories pages in those 4 Groups and in that module only the pages you actually want to list would be shown. It only would need to check what Modules have been installed. Beside that you would be able to translate all the documentation into multiple languages as a global effort. Many German customers don't like an English documentation, the same like Americans don't like a German one. Also you could ed lots of multimedia stuff i.e. the existing videos in that appoach. For those who want to have an option to read their docs also offline could store it locally for later usage. Nevertheless this documentatin should follow always the same base structure otherwise the Processwire documentation would look like a total chaos. Another huge benefit of an online centralized documentation is the fact that it can be kept very easily. If using even something like Google Docs you would have even Versioning in there so you could see what changes have been made over the time. I would not reinvent wheels but simply use the tools which are already available - mostly free - to accomplish that job. Using much less developer resources to maintain the whole stuff with Versioning you have a very good review and can manage different authors it is possible to integrate images and videos etc. ...Andi