Skip to content
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

Open
jkobus opened this issue Jul 17, 2017 · 6 comments

Comments

@jkobus
Copy link

jkobus commented Jul 17, 2017

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.

@Nyholm
Copy link
Member

Nyholm commented Jul 17, 2017

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
Copy link
Author

jkobus commented Jul 17, 2017

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
Copy link
Member

Nyholm commented Jul 17, 2017

Thanks

Could you send a PR to the docs?

@jkobus
Copy link
Author

jkobus commented Jul 17, 2017

👍

@Gladhon
Copy link
Contributor

Gladhon commented Mar 20, 2018

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants