-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command translation:download downloads translation in xliff format rather than the one already used #15
Comments
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. =)
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. |
Thanks Could you send a PR to the docs? |
👍 |
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? 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? |
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.
The text was updated successfully, but these errors were encountered: