I like this idea. But I'd think a bit more about the options of the command. It's common for this kind of commands to have two modes: 1) "show the changes to do but don't make them", 2) "make those changes".

In this example, --fix seems the option that makes changes ... but there is a --reorder option that makes changes too.

The other issue to think about is if we want to allow to select the fixers: reorder, add missing, etc. or we want to run all of them at once.

Finally, I'd like to have a list of proposed fixers. For example:

• reorder: changes translation files to have their contents in the same order as the original translation file.
• add missing: changes translation files to add all the translations defined in the original translation files and missing in this particular translation files.
• ...

@javiereguiluz I agree with you, it makes sense to make changes for --reorder option only with specified --fix option.

I suppose, we'd like to have some format-specific fixers, for example, for YAML translations:

# inline
post.no_comments: No comments
post.no_posts: No posts
# or expanded
post:
    no_comments: No comments
    no_posts: No posts

I'm also wondering in the best way of original translation determination. I think we should provide --default-locale (or just --locale) option for it which helps to determine original translation file i.e. the file, which will be used as the basis for --reorder, --add-missing, etc. options.

@bocharsky-bw did you considered translation:update on this? Maybe we should avoid having 2 commands doing write operations..

Ie. extending the update command with --file could work? Point is --add-missing feels like translation:update.

translation:update --reorder --dot-notation --no-add-missing can be considered as we have many options to tweak already.

Last but not least, the command could be moved to the translation component like the yaml:lint command.

Hey @ro0NL , I think single lint:translation command with a few options will be enough for these purposes. We already have lint:twig and lint:yaml similar commands. BTW, the yaml:lint command is deprecated and doesn't work in Symfony 3, so lint:translation looks like a better name here.

What about formatting YAML translation files: I think doing the same operation with different commands is a bad idea. The command should determine translation file format by itself and process it properly.

Maybe you're right, and 2 commands could work

• translation:update updates files based on source
  • functional related -> we need all strings in a file
• lint:translations updates files based on a template file
  • cosmetic related -> we need to organize our files in a sane way

About (re)formatting; this only affects inline vs. expanded (ie. dot notation yes/no) and is definitely translation related, but only for YAML+PHP. Im more or less leaning to something like LoaderInterface::supportsDotNotation to avoid tracking a list of extensions somewhere.

There are quite some bundles that do a nice job on this, or am I mistaking on the scope of your issue here? ;)

https://github.com/schmittjoh/JMSTranslationBundle
https://github.com/lexik/LexikTranslationBundle

A command changing the file should not be named lint:* IMO. As soon as it fixes things, it is not a linter anymore.

Even if this idea is changed to only provide a linter command and not a fixer, I'd love to see it happen.

(Context -> this morning, a minor error in a XLIFF translation file completely broke a bundle release: https://github.com/javiereguiluz/EasyAdminBundle/pull/1490)

@javiereguiluz we right now have the yml linter in our test suite, which saved us from releasing broken bundles several times already. So 👍 from me on that specific context too.