One of the goals of Drupal 8 Multilingual Inititive is to refactor Gettext file handling by a component. The first effort was
Make gettext .po generation its own abstracted functionality by Gábor Hojtsy, Sutharsan, fubhy, sun and clemens.tolboom
While I (clemens.tolboom) was working on that issue I skimmed over the Translation component delivered by Symfony to see whether we could match their architecture (why reinvent components?) or even take over their components.
Progressing further and discussing progress with Gábor Hojtsy and sun on #drupal-i18nsun suggested to create a new issue trying to use the Symfony Translation component and see what happens with
Let Symfony Translation component handle language messages.
This lead me into a new world of GPL versus MIT, php development, git squash, github pull requests etc.
Here are some experiences from my
pull requests for Symfony (click closed button to see all.)
Experiences
Licenses and the copy paste cat
My initial D8MI related pull request
Drupal gettext was a bummer as I added a slightly changed and objectified copy-paste version of some parts of gettext.inc forgetting GPL does not allow loosening the license into a MIT version.
git squash et al
By having a pull request the receiving party wants a clean commit. But as a developer you commit every new feature into a local commit to make cherry-picking possible. For this to work you need to squash all commits into the commit belonging to the pull request.
Thanks to
stloyd pointed me to
Using Git Rebase to Squash Commits explained a great deal to me and http://symfony.com/doc/master/contributing/code/patches.html
Should we go using Symfony Translation component
The Symfony
Trans2drupal pull request is developed based on the patch for Drupal
Let Symfony Translation component handle language messages. That introduces a brittle dependency as it is not committed. It is not actively commented too. So that's not comforting.
The flip side is we can drop a lot of code and focus on our Drupal code when the pull request lands. In writing the code I learned new ways of coding (more PHP less Drupal) which is nice.
Image taken from http://www.mjdinteractive.com/mjd-blog/2012/04/drupal-8-to-utilize-symfony-2-components/
Comments
The GPL bit is unfortunate.
The GPL bit is unfortunate. We'll have to be careful about that.
btw, You wrote GLP in the 4th paragraph when you meant GPL.
squash is bad
It flies against a couple thousand years of scientific practice to throw away the notes leading to a discovery, or in this case, the code. It doesn't hurt anyone to see a single line commit saying "typos". The mainline history should contain nothing more than just merge this feature, merge that branch and then only those who actively seek the the detailed information can see it -- but they can see. If you squash you lose information. Never do that.
I totally agree ... partly :p
I totally agree ... partly :p
While working on my Symfony pull request I also did stupid things. Those are only interesting for Historians interested in the developer experience.
What I 'discovered' while squash-ing was I can keep (merge) all commit messages into one commit.
Locally I was annoyed have squash-ed my commit as that disallowed for cherry picking. So I have to figure out how to do that and still comply to the Symfony way.
Note that Drupal does squash-ing all the time by using patch files :p