build2be/com/e

As a followup on A pinch of Symfony for D8MI? why do we need to squash?

After some more squash and push -f attempts regarding pull request for Symfony I get the hang of it.

But chx said in squash is bad as we loose history on the development process.

So how should we do this on d.o when git phase 3 lands? Those discussion seems to got to a halt.

For reviewing patches I try to use mostly http://drupal.org/project/drush_iq

Get latest code base

Take an issue from the Issue Queue

Use the issue id or the issue id#comment to get a particular patch #

Reinstall Drupal and work on the patch

Do what you have to do make Drupal work (again). And test or run tests

Trying to gra(s)p(h) Drupal\Tests\Core\Cache\BackendChainImplementationUnitTest

Trying to convert BlockStorageUnitTest to a real unit test. It seemed trival.

Below a graph generated from the module list of a Drupal 8 development site.

We all know Drupal and Symfony do have multilingual support (i18n, l10n, pluralization). But do they match? Or do they equally well? How does one test this? This is what I did.

I wanted to add tests for Symfonfy's PluralizationRules as there were none and I wanted to have support for PluralForms loading Drupals *.po files clean and simple. How hard can it be?!?

These tests should cover:

While still working on D8MI Let Symfony Translation component handle language messages I needed to code for Symfony to on the Translation component.

So how does that work writing and testing Symfony code?

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.