ongr-io / translationsbundle Goto Github PK

If there are changed translation files in push - reimport.

Current situation:
Running app/console ongr:translations:import Foo\\BarBundle\\FooBarBundle imports only keys (no locale translations) due to nulled locales not matching anything. See: https://www.dropbox.com/s/wussq60g5v2qgix/Screenshot%202015-03-02%2014.06.35.png?dl=0

Running app/console ongr:translations:import imports everything.

Proposal:
When specifying one filter option (bundle/domain/locale), others should remain match all, thus running app/console ongr:translations:import Foo\\BarBundle\\FooBarBundle actually imports something useful.

Filter Manager now has an additional argument in its constructor - event dispatcher. The bundle fails when it tries to create a definition of filter manager without it:

Check other classes too.

Currently TranslationManager is responsible for adding new objects like messages and tags to translation documents. The process is being handled by addObject() method, which at the moment does not add any objects to the given document:

The result of this is that the bundle is not capable of adding tags or new messages to translations

http://ongr.readthedocs.org/en/latest/components/TranslationsBundle/setup.html#step-3-add-configuration

vendor/ongr/translations-bundle/Storage/ElasticsearchStorage.php:53
vendor/ongr/translations-bundle/Storage/ElasticsearchStorage.php:57
new TermsFilter('locale'... key is invalid. Should be 'messages.locale', same with domains.

From conversation in #52.

• Import
• Export

Scenario: Added "en", "de" and "lt" to config, imported translations from bundle and I see only "en" and "lt". Why? Because there were no translations in "de". Current implementation lists translations based on data in ES. What if I want to translate to new language? It should be enough to add new locale in config.

Uncaught PHP Exception Symfony\Component\Debug\Exception\UndefinedMethodException: "Attempted to call an undefined method named "isRelevant" of class "ONGR\ElasticsearchBundle\DSL\Filter\TermFilter"." at /{edited}/vendor/ongr/filter-manager-bundle/Filters/Widget/Choice/SingleTermChoice.php line 80

When trying to select any domain in UI.

With filter-manager 0.4.2.
Updating filter-manager to 0.5.4 seems to solve this.

Open for better ideas.

Preview could happen on STAGE, while pulling translations from LIVE's DB (read-only access, so should be safe).

Input field for translation is way to small to be usable. At the moment only work-arounds helps (like a copy-paste)

How about doing AJAX and trying to load that specific key in specific locale seeing if it would crash?

Currently import command requires "full bundle namespace". It should support short form (e.g., ONGRTranslationsBundle).

Also whole import service should be reviewed. Probably it's overcomplicated. (Tip: see Kernel::locateResource().)

EDIT: it looks like configuration also ask full namespaces.

Having multiple translations it's very easy to miss untranslated items by simply browsing through pages.

Would be nice to be able to filter by missing translations by locale.

https://www.dropbox.com/s/sbrdrx1230nwysz/Screenshot_2015-04-10-08-24-24.png?dl=0

Nexus 5, Lollipop 5.1, latest Chrome.
Request desktop version - turned off.

Translation should have dirty flag showing if translation has been exported after editing.

• Bundle name from which it was taken.
• Translation path
• Property group (string) -> tags (object)

In Import service importComponentTranslationFiles() method, we are importing some symfony components translation files:

Few places stopped working after ESB 1.0 integration. Because of lack of tests these were not spotted until now.

Best way to catch all of them would be to setup demo project and test all actions available in UI. Commands looks to be working well.

Few spotted places:

• History document has public properties, but various services calls getters and setters. Public properties should be replaced by getters and setters.
• TranslationManager tries to get document from document iterator by key. This wont be supported by ESB 1.0

Relates #60

Particularly for mobile dev, we'd need a way to limit the translations to a certain width, where a maximum width was defined. Ideally this width is defined in terms of #pixels

3 steps action:

1. Show pending changes (see #27)
2. Confirm export
3. Execute custom shell script (which HAS ongr:translations:export and other required commands)