German (de-DE) not maintained

[mr-fan]

Is the lang file in the download section http://modules.processwire.com/modules/german/

uptodate or have i to look / and post new translated files here?

Newbee question....

how i can translate name and desc fo a module?

If i add new one with the adminmodule for translation i'll get the used strings in the module itself but not the desc that shows up in the modules overview for example?

Best regards mr-fan

[Manfred62]

the german lang pack is up to date for the PW 2.4. You can also take it directly at Github:

https://github.com/yellowled/pw-lang-de

if you want to work with the newest PW dev version, than you need to replace some files (look at files from the post above yours).

Name and description of modules depends on the module itself. Following strings are needed to be translatable:

    public static function getModuleInfo()
    {
        return array(
            'title'     => __('Diagnostics Page', __FILE__),
            'summary'   => __('Allows evaluation of run-time environment and detection of changes.', __FILE__),
...
...

[Manfred62]

I have placed the first 4 module translations for german on GitHub --> https://github.com/Manfred62

ProcessDiagnostics

Thumbnails

ModulesManager

CKEditor

not sure, is it helpful to always translate the module title?

Suggestions and corrections welcome.

[mr-fan]

Addes first draft for Blog Module....but there are some strings that not translatable until now...created git request for it.

I didn't get all strings but the most of them.

Best Regards mr-fan

site--modules--processblog--processblog-module.zip

[Manfred62]

new german updates for actual PW dev 2.4.2 (28 May 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack).

updated files:

wire--modules--inputfield--inputfieldinteger-module.json

wire--modules--process--processpageadd--processpageadd-module.json

added file:

wire--modules--fieldtype--fieldtypepagetable-module.json

pw-lang-de-dev-update.zip

[owzim]

I can't find the post. I remember that we talked about having a Github repo for all german translation files for all modules, so I am not aware of the current state of discussion there. Does anyone know where that post is?

Edit: found it https://processwire.com/talk/topic/2583-delivering-module-translations/?p=41767

I think that discussion also belongs here?

Were can we even find module translations?

[Nico Knoll]

Sounds fine to me - but I'm not sure if it's better if ryan creates these repos as "official Processwire Repos" or like - how we do it now - someone from the community opens it...

[Soma]

I find it very confusing to have everything in the backend translated. The modules especially or at least the titles shouldn't be translated, it makes it vey hard to communicate and will split devs by language. Once we discussed about translations in admin when it was newly introduced, and wanted to at least translated everything an editor would use and haven't put focus on admin parts.

I was about to write a lengthy post about dev's should at least know some english... but screwed it, and don't know what to think of it and thought ok I still can set my admin user language to english! Hah! Well doesn't work cause my project has default german and there's no english only french and italian. Now I can't get the english back and am constantly looking for modules. I need some way to turn it off or something. If only would now how.

Edit: To go further there's no translated version of those module on the internet, the repo is english only. (including core ones)

[owzim]

Soma, I am with you on the part that devs should know English and Modules that are solely used by devs should probably not be translated. But there are modules or parts of modules that are used by the actual CMS user so that should be in the same language as the rest of the UI. Are you suggesting that even the users should have an English UI?

Sounds fine to me - but I'm not sure if it's better if ryan creates these repos as "official Processwire Repos" or like - how we do it now - someone from the community opens it...

That's what I meant. Have one repo for German translate files for modules maintained by one German and contributed to by other Germans. Is there one already?

[Manfred62]

I remember this discussion too. Also Matthias (yellowled) and I talked about how to handle this, but with no final solution.

Best would be:

one general repo per language (under the roof of official PW?), including "sub-repos" for the basic lang-pack and every translated module. Is such a hierarchy in GitHub possible at all?

Also I agree with soma: not absolutely translate the module titles, but the descriptions and the rest of it.

[Soma]

Yeah I was speaking about things only visible to devs, but it would feel odd and there's no clear line or hard to see/know, so as said the modules title makes sense to me not to translate. This wouldn't be too bad as everyone would be speaking of "ModulesManager" and not "ErweiterungsVerwalter".

[owzim]

[...] "ModulesManager" and not "ErweiterungsVerwalter".

lol, the title should definitely stay English

[yellowled]

Yeah I was speaking about things only visible to devs, but it would feel odd and there's no clear line or hard to see/know, so as said the modules title makes sense to me not to translate. This wouldn't be too bad as everyone would be speaking of "ModulesManager" and not "ErweiterungsVerwalter".

Personally, I would not even consider translating that because ModulesManager is more like a proper name. You usually don't translates proper names. (By the way, Soma is very right considering fragmenting discussion by translations. I have experienced that in a forum for another system. It's very hard to switch. However, it's something you can't really avoid – once a system is translated, people will discuss it in various languages.)

The issue at hand with this is still if we should put module translations in the “core” language files or not. Personally, I don't think it's a good idea. It would blow up the language packs significantly, which is not ideal for people who don't use many modules. (I, for instance, tend to not use many modules in most of my PW projects.)

As for keeping all translations for modules in a seperate repository, I don't think that's much better. The repository will grow rather quickly, making it hard to install only the few translations people actually need, especially given the fact that the file names for translation files are kind of clumsy. I think the only option there would be to keep the modules in seperate directories of that repository.

I don't know if that's feasible, but maybe module translations could get some kind of a “dependency management”? Currently, if you install a translation, you just upload a zip file including all core translations. (At least that's what I do.) It would be very awesome if there was a way to (for each language installed) easily “get all available translations for modules currently installed”. (Might be kind of an overhead, though. Not sure. I'm not a coder.)

[yellowled]

Oh, also something to think about – I don't know how you guys handle this, and it obviously depends very much on the project and the modules used.

I think translations are (mostly) for users, e.g. editors. Admins should be able to handle a PW backend in English, although I wouldn't call it a requirement. However, I wouldn't know how someone who doesn't read English would even be able to understand PW enough to administrate a PW installation. Most of the documentation is in English only.

So in most of my projects, clients have a “backup” admin account, but use PW as editors, which means they don't get to see much more than the page tree, which is a core feature. What I'm trying to say is maybe we're overthinking modules translations quite a bit here. Yes, they would be nice to have, yes, it would be nice to have a way to easily install them. But if someone definitely wants a module's backend section translated, a bit of work to install the translation should be fine.

[mr-fan]

Hi guys,

like i wrote i'm new. I'm testing PW into the deep if it is the right step for me and my projects...

i don't know the history of the handling of the landguage files...but for me there is only one question:

Why they aren't shipped with the modules itself?? It's the easy and common way from very much systems with no overload of the core file?

This would require a structur with a subfolder namded like the lang de fr or something so it should be easy to search modules for langfiles to edit them in the manner way.

only my newbee 2 cent (sorry if i have missed a feature of PW that makes my answer beeing nosense )

Best Regards mr-fan

[MadeMyDay]

Hi guys,

like i wrote i'm new. I'm testing PW into the deep if it is the right step for me and my projects...

i don't know the history of the handling of the landguage files...but for me there is only one question:

Why they aren't shipped with the modules itself?? It's the easy and common way from very much systems with no overload of the core file?

This would require a structur with a subfolder namded like the lang de fr or something so it should be easy to search modules for langfiles to edit them in the manner way.

only my newbee 2 cent (sorry if i have missed a feature of PW that makes my answer beeing nosense )

Best Regards mr-fan

Well, this could be done. But ProcessWire doesn't work with common language strings. If a developer codes a module all he has to do for being translation-ready is to put something like __('this is my string I want to translate') in his code. This is very handy because you don't deal with cryptic language variables.

The downside is, you (or someone) has to use the language translation module to point to the file with the translation but then has a very comfortable way of translating it. Once a language file is translated a json is generated which can be used by everyone. The problem is, this file is located somewhere in the file system (look at the url while translating, identify the id, look in site/assets/files/id where you find all the translation files).

I think what we (and Ryan) could do is to encourage module developers to create an (even empty) language file and ship that with a module (like ModuleName/lang/en/site--modules--ModuleName-module.json. So the only thing you have to do is to upload this/these json file(s) to your language and translate it. After that you could do a pull request to the project, so it could be easily integrated for others.

Another problem is that these language jsons are named by the module path. And if not installed by ModuleManager, everyone can at least name the folder differently. 

But providing (even empty) jsons would be a good start I think.

[yellowled]

Why they aren't shipped with the modules itself?? It's the easy and common way from very much systems with no overload of the core file?

Well, one problem would obviously be that you'd have (at some point) translations for all languages in the module's repository. I think PW is currently being translated into 18 languages; it's likely to get more over time. For most sites, even multi-lingual sites, that would give you 10-15 or more unneccessary translations in the module's repository.

I think it would be way better to bundles translations with the modules they belong to, so your idea is basically a good one. However, I still think it needs some kind of system to detect which languages should actually be installed in any given PW installation.

[Nico Knoll]

Maybe you could add a "check for new translations" button to the language settings. This button would glob() recursively through the modules folder and collect all of the language files. These files should follow a conviction like "ProcessProgress.de.lang.json" or have some kind of install information in it to let the crawler recognize to which language the files belong.

[Manfred62]

new german updates for actual PW dev 2.4.3 (31 May 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack).

updated files:

wire--modules--inputfield--inputfieldfile--inputfieldfile-module.json

pw-lang-de-dev-update.zip

[Manfred62]

new german updates for actual PW dev 2.4.4 (12 June 2014).

Zip contains only updated/added files (in comparison to the default 2.4 lang pack).

updated files:

wire--templates-admin--default-php.json

wire--modules--fieldtype--fieldtypepagetable-module.json

wire--modules--system--systemupdater--systemupdater-module.json

added files:

wire--modules--process--processpagelister--processpagelister-module.json

pw-lang-de-dev-update.zip

[adrian]

I have no need for the German language pack , but I am always so impressed about how quickly you are on these updates. I am sure lots of users are super appreciative!

[Nico Knoll]

Thanks, Manfred! (Have you added them to the GitHub Repo, too?)

[yellowled]

Thanks, Manfred! (Have you added them to the GitHub Repo, too?)

It's kind of unclear how to handle this for the GitHub repo. So far, we have only included versions matching the stable releases of PW there, meaning it has tags for 2.3 and 2.4. I'm not sure if it would be a good idea to continously upgrade it with 2.4.x versions. Then again, I don't really see side effects here, at least not at the moment.

I would like for these to be consistent, though – i.e. not skipping versions. Not sure if it's feasible to have seperate versions of the lang pack for any patch version.

That being said, I'm happy to do it the way you guys want to as long as there are no technical concerns (which I don't see as of now; might happen if lang packs become installable from the backend like modules one of these days).

[MadeMyDay]

Why not maintain two branches according to the PW branches? stable and development?

[yellowled]

Why not maintain two branches according to the PW branches? stable and development?

Fine by me, but this will make it harder to maintain the repository. I'm not sure if all contributors (most of the commits by now come in via pull-requests) will be able to work with different branches. (Yes, that is not a good reason not to do it, I'm merely pointing out that it's more prone to error than the current setup.)