[Translator][Console] translation:update yaml nesting

[NinjDS]

Nesting translations message codes (the dot being the separator) is a great feature of YAML translation files:

admin:
    title: Administration
    exit: Exit administration

You can then use admin.title and admin.administrationin your templates with the trans filter.

But the translation:update command cannot issue nested messages. Currently, it simply lists all messages, and turning that big file into a nested one is a pain.

I guess it wouldn't be too hard to achieve: build a tree with existing translations, and a tree with new ones, then merge the two trees and write the file again.

[NinjDS]

Ok i added this functionality, but i have a question for its integration: how to add the option?

1. Command line: i suggest two options: add a format ("yamlnest") or add an option ("--nest") which would work only with format yaml
2. Framework code: how to carry this option from the command line to the place where the tree building should or should not take place (Symfony\Component\Translation\Dumper::format()) ?

Thank you

[NinjDS]

Well, i picked up an option and did it that way, is that correct?

In Symfony\Bundle\FrameworkBundle\Command\TranslationUpdateCommand.php: added an option --nest-level with REQUIRED_VALUE added an entry to the options passed to $writer->writeTranslations(), stating this value

In Symfony\Component\Translation\Dumper\YamlFileDumper.php: i use the value from the $options array argument of dump() to save it in the YamlFielDumper class, then it's used in the format() function of this class to know weither to build a tree or not.

I'm still looking for how to attach code files with diffs to github (new to it), but i would like to know if the way i did it is the right one. Thank you!

[NinjDS]

Is there any SF2 admin watching this tracker? :(

[fabpot]

sure. I'm not comfortable with added specific options for specific formats. I would prefer to add a snippet of code in a cookbook to explain how to convert the flat structure to a nested one.

[NinjDS]

Hi Fabien, thank you for answering,

I understand your point of view. Indeed if every format variation had its own code it could become a mess.

However here i'm speaking about a Symfony feature. SF2 natively supports translations messages nested by dots, so i thought it was missing here, since it's much easier to work with nested YAML for translations. The fact that SF2 allows reading nested version but not writing it semt to me like a broken bidirectional feature :)

Also, even with a trick for turning line-by-line YAML messages codes to nested structure, it would require to do it after every translation:update, which would fast become a big overhead.

I'm working in real-time with translators for my current project (4 languages so far) and i think allowing the update command to output nested YAML instead of line-by-line can lead in significant productivity gain, which is SF's main headlilne i think :)

Anyway, my code is ready, works, has been tested, is properly integrated as stated by the /contributing/code/patches.html page of the doc, so would you like to give it a fast look (few lines are commited) or should i just forget about it?

[fabpot]

As I said, I think it would be better to add this is to the documentation. And of course, it's then up to you to package that as a command if you are using it all the time. But as YAML is not a standard format for translations (like XLIFF or gettext), I don't want to add too many specific features for it.

[NinjDS]

Alright.

So what should i do to share my work in this case? I extract my changes from SF bundle and make my own command extension, then where to go to share it officially?

Well or i could just make a bundle, but it's a little too much overhead for such a small purpose i guess.

[fabpot]

As I said, as I expect the code to be quite small, it can probably be included in the official documentation where we talk about this command.

[NinjDS]

Not sure i understand how, but wait, i'll make a PR so you get the code attached. Sorry because i'm not very comfortable with github yet, so i think the best way to show the code is to have the diffs available, and i found only the PR solution for that. BRB

[NinjDS]

Ok, looks like it's done, sorry if that wasn't the right way to show code changes (i saw some link to the diff of my branch but wasn't sure how to integrate it to this discussion).