en_us translation should be in core

[Engelbert]

The default language en_us should still be in the ProjectPier-Core Repo because we need a base language for usage and development.

[JonDeG]

I was planning to pull the languages into folder with the build script. But we can leave en_us in the core repo if you wish. We would do the same with the plugins then or no?

[Engelbert]

Mmm, en_us file does not have to be in the ProjectPier-Core repository. It ain't necessary for development, but it might be handy to have it in there... If we leave it out, ProjectPier-Core is not usable if you just clone the repo. To solve this the build script would have to create a "nightly" build for us to develop in/on.
The standard plugins that provide core functionality ( tasks, milestones, ... ) should stay in the core too if we want to be able to clone and develop, or the build script pulls them in too... I don't know what works best...

We might have to think this through Jon... Before we go on...

I have been thinking about the languages a bit further, and we can go two ways with this imo.

• all languages including en_us out of the ProjectPier-Core repo
  • Language files in lang folder with every single string in there and no more lang folder in the plugin repositories
  • en_us file in the translations repository will need to be updated with all new, updated strings once every release cycle after we feature freeze.

We will need a script that gives us the new untranslated strings, or we will have to enter them all manually.

• things stay the way they are and we have a lang folder in every plugin. That script I mentioned above could still be useful though.

[JonDeG]

Currently the build script below is pushing a nightly build to https://s3.amazonaws.com/pporg/builds/projectpier-master-latest.zip

This script would be expanded to pull in the translations as well. Basically the application is not usable upon direct checkout, it must be built. This gives us flexibility of having separate locations to file bug reports per plugin. It also gives us flexibility to package builds, for example, without translations or plugins that are not ready for production. Of course as you pointed out it is at the cost of not being able to checkout and install directly. I'd vote we either keep all the plugins and translation into the core repo (as it was) and use the build script to delete the plugins/themes/translations that are not production ready, or separate them all out (the track we're on) and use the build script to pull together nightly builds and releases. Another words, not try to structure the repos for release packaging.

Relating to language folders in the plugin directories, I like to look at it from the responsibility perspective. If someone takes responsibility for a plug-in, they probably don't care so much about all the translations. As a programmer they would only be concerned with the code and no idea how to translate words into other languages, at least not all of them. Then, from the perspective of someone managing a language, they care about their language of choice throughout the entire application, not just within one or two plugins. Therefore, my vote would have to be with combining all the translation into a single language folder as you described.

# File system prep
rm -rf *

# Checkout the core
git clone https://github.com/Project-Pier/ProjectPier-Core.git ./core
rm -rf ./core/.git

# Checkout the Files Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Files.git ./plugin-files
rm -rf ./plugin-files/.git
cp -R ./plugin-files/* ./core/

# Checkout the Form Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Form.git ./plugin-form
rm -rf ./plugin-form/.git
cp -R ./plugin-form/* ./core/

# Checkout the Links Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Links.git ./plugin-links
rm -rf ./plugin-links/.git
cp -R ./plugin-links/* ./core/

# Checkout the Reports Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Reports.git ./plugin-reports
rm -rf ./plugin-reports/.git
cp -R ./plugin-reports/* ./core/

# Checkout the Tags Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Tags.git ./plugin-tags
rm -rf ./plugin-tags/.git
cp -R ./plugin-tags/* ./core/

# Checkout the Tickets Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Tickets.git ./plugin-tickets 
rm -rf ./plugin-tickets/.git
cp -R ./plugin-tickets/* ./core/

# Checkout the Time Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Time.git ./plugin-time
rm -rf ./plugin-time/.git
cp -R ./plugin-time/* ./core/

# Checkout the Wiki Plugin and copy to the core
git clone https://github.com/Project-Pier/ProjectPier-Plugin-Wiki.git ./plugin-wiki
rm -rf ./plugin-wiki/.git
cp -R ./plugin-wiki/* ./core/

# Create output folder and generate build date ID file
mkdir ./pkg
cd ./core
date -u > build_id.txt
echo Jenkins Build ID $BUILD_ID >> build_id.txt

zip -r ../pkg/projectpier-master-latest.zip ./*

[Engelbert]

👍
Let us go ahead with our divide and conquer strategy then.
Languages and plugins separated seems the way to go.