Attention all language pack devs: simple dev environment for language packs

[dotnetic]

My ProcessWire environment for language packs provides an easy way for translating your language pack.

You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository.

This is a boilerplate which could work with any language, but right now it is tailored to the german language pack.

If anyone is working on a language pack, let me know how it works out, or if you need changes or help.

[MoritzLost]

Hi @dotnetic, thanks for maintaining the German translations, we use it in most of our projects ?

Quote

It is mainly ready, I just have to figure out the best way how you can make a PR for the pw-lang-de submodule. If somebody has exp with this, please contact me.

What are you having trouble with? I would use Composer scripts for both initializing the environment (importing the database) and copying the translation files to the submodule directory. I see you already have a composer.json in your repository – if you put the restore.php in a Composer script and add it to post-install-cmd, the database will be restored when you execute composer install. Likewise, you can add a script that copies the translation files to the submodule's directory. Then one just needs to cd into the submodule and commit the changes.

[dotnetic]

1 hour ago, MoritzLost said:

What are you having trouble with?

The problem is not the setup of the dev environment. Composer would be just another way which saves you one or two steps that you would have to make manually (but I like the idea. I will consider it).

I tried to figure out how a contributor can submit his changes to the pw-lang-de submodule. Because he clones the pw-lang-de repo as a submodule he won't be able to submit to this repo. 

So the steps that I thought of are:

Fork the pw-lang-de submodule on github so you can submit to it and make a PR.

Then you could simply clone the processwire-language-pack-helper (dev environment) and add the forked repo as a submodule. After making changes you can make a PR from your forked submodule to the german language pack pw-lang-de.

What do you think about this?

[MoritzLost]

Quote

Fork the pw-lang-de submodule on github so you can submit to it and make a PR.

Then you could simply clone the processwire-language-pack-helper (dev environment) and add the forked repo as a submodule. After making changes you can make a PR from your forked submodule to the german language pack pw-lang-de.

Sounds solid to me. If you want to accept translation changes in the form of pull requests, a contributor will be required to fork the pw-lang-de repository in any case. However, you can still include the submodule in your repository and people don't need to add it manually. Once a contributor has cloned the repository, they can go into the submodule and add their own fork as a remote:

$ cd site/assets/files/1019
$ git remote add fork https://github.com/<user>/<pw-lang-de-fork>

Then they can do their updates, commit the changes and push to their fork instead of the original repository:

$ git add .
$ git commit -m "Update translations"
$ git push fork master:master

Or is this what you meant? ? Anyway, I think that's the most efficient solution with your current setup!

[dotnetic]

Thanks Moritz.

My method described that you don't add the official pw-lang-de repo as a submodule, but the forked repo instead. 

Your method adds the forked remote to the submodule so they can push to their remote.

I think I will mention both ways in the README, so one can decide which route he takes.

[MoritzLost]

2 hours ago, dotnetic said:

My method described that you don't add the official pw-lang-de repo as a submodule, but the forked repo instead. 

But doesn't that mean the contributor has to manually add their own repo as a submodule? That seems unnecessarily complicated. It comes down to the same thing anyway. A submodule can have multiple remotes, so both the original and the fork can be added as remotes (to keep in sync with upstream changes, while commiting to the fork).

[dotnetic]

Yeah, thats why I left it and updated the instructions: https://github.com/jmartsch/pw-lang-de/blob/master/README.md