-
Notifications
You must be signed in to change notification settings - Fork 17
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
Appending TranslationStrings to each other #17
Comments
Why not leave off the message = 'phrase1'
mapping = {'b': 'Bar'}
if a:
message += 'phrase2 $b')
else:
message += 'phrase3 $b')
if b:
message += 'phrase4'
return _(message, mapping=mapping) |
I tried it this way but then it prevents the .pot file generators (like lingua's pot-create) from including the strings in the created file. |
In my experience, making any assumptions about the structure of a sentence or phrase across languages is incorrect. Each phrase, in its entirety, needs to be translated independently, thus this type of concatenation should be avoided and you should just interpolate the |
Each phrase should be translated independently. But without concatenation, the only way to pass the TranslationString somewhere (e.g. template or flash message) would be to translate the components of the message individually, concatenate the resulting strings, then pass the result on. Like this:
But if your templates or flash messages can automatically translate a TranslationString (which is quite easy to set up in Pyramid), it would be much cleaner to do (where TranslationString's
After all, if you were returning a 'regular' TranslationString instead of a compound one, you would likely just do this:
Having some sort of compound TranslationString would allow application Pyramid views to not worry about translating strings themselves, and treat 'regular' and compound TranslationStrings the same way. Because the way I handle this now is return either 1 TranslationString, or a |
I see. I agree it would be nice if they could be appended in the way you're describing. |
This could perhaps be an alternative to #10 about nested translations, for when a TranslationString's mapping contains another TranslationString. Where instead of nesting them you could append them. |
I programmatically build up TranslationStrings based on what the content of the message should be. (A common pattern when building up for example an error message based on several conditions to be displayed somewhere like a flash message in Pyramid.) Something like
This doesn't work when I pass it to Pyramid code for translation because by the time I've appended the TranslationStrings to each other it's already a string before it reaches Pyramid. If TranslationStrings are appended to each other it would be good if they would be retained as some kind of compound TranslationString where running the translate function on it would allow each of the sub-TranslationStrings to translate themselves from the .mo files. And to be able to apply a mapping to the compound TranslationString (the last line above) or to each TranslationString that makes it up.
The only alternatives I see to this solution are messy. Either I return several message parts to Pyramid, like return (message1, message2, message3, message4, ...). Or each condition above has the full message, like below, which would lead to repetitive code and also duplication of effort by translators.
The text was updated successfully, but these errors were encountered: