loco-adapter
loco-adapter copied to clipboard
php-translation
Command translation:download downloads translation in xliff format rather than the one already used
In my testing setup I was using yml for storing my translations but the translation:download command downloaded xlf files. Expected behaviour would be to replace the contents of the yml file.
Now, the order of translations - both in yml and xlf format is hard to predict. I guess that symfony somehow prioritizes xliff files above yml, as xliff is the recommended format.
Let me know if that's an expected behaviour.
An easy fix for that would be to add an option where user can specify desired format.
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.
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.
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
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?
