Search the Community

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.