Command translation:download downloads translation in xliff format rather than the one already used about loco-adapter

[Nyholm]

This is how I reason about this. Im not sure it is "the correct answer" but it is something I currently believe in.

Since we are using Loco, we should not care how translation are stored on our local disk. In fact, we should not have translation files in git. Since XML is far better than any other format for all aspects (but readability for humans), it should always be used. Especially since you never read the translation files anymore. You read them in Loco, sf web profiler or the web ui.

I've know php-translation has a quite rough "getting started, import your translation" procedure. It is also fairly undocumented. You should basically import what you got to Loco and then throw away your translation files. =)

An easy fix for that would be to add an option where user can specify desired format.

Yes, agree. Though, I argue above why I think this is not needed. However there is no reason why we should not have it. Im happy to review and accept such PR.

[jkobus]

I agree. I started using XLIFF; we had problems with YML files in the past: long translations, translations with html, multiline translations etc. For now, a small update for the docs would be enough; something stating that the XLIFF is the supported and recommended format.

[Nyholm]

Thanks

Could you send a PR to the docs?

[jkobus]

👍

[Gladhon]

i disagree. It's okay if you have xliff as default format. But i expected that it will use the config output_format - which seems for me the right place

[arendjantetteroo]

Where should this change be made, in the loco adapter or somewhere else?
I would take a stab at an implementation PR if you can give me some pointers.

As a workaround i will remove my yml files on deploy and then download from loco. Having some sort of fallback seems usefull but i guess i should then replace the yml with xliff anyway?