Unneccessary breakage sometimes in updated pot files

[mattbrunetti]

Ideally we could shift around (refactor) code without causing changes to the generated .pot files (unless the changes actually changed the translatable text)...

There are two things (sub-issues, if you will) that sometimes prevent that:

1. If my template at first has Welcome {{$ctrl.userName}}! and that changes to Welcome {{$ctrl.user.name}}!, the new generated pot file will have the first string removed and the second one added, and there will be translation work to do. We could avoid this if angular-gettext-tools extracted either string as Welcome {{1}}! and then angular-gettext knew to use that regardless of the interpolated code. This is the important one

2. The generated pot files have comments above every message entry, indicating what file (and optionally what line number) the message was extracted from. So, when that location changes, even if the message itself hasn't changed, there is a change in the generated pot file and it looks like there is translation work to do. We could probably include an option like filenames: Boolean in angular-gettext-tools to handle this. Not as important I think, since we can configure postProcess option like so: postProcess: pofile => pofile.items.forEach(item => { item.references = [] }), I realize that this sub-issue belongs to the angular-gettext-tools package alone, but I included it here for the sake of having a generalized issue

@rubenv Do you have any thoughts on this? (Really just interested in the 1st) Are you interested in a PR that would fix this? Would you want the changes to maintain backwards compatibility? We could make the new behavior opt-in. Or would you agree that it's better to make this the default behavior and allow a breaking change that necessitates a major version bump?

I love these packages, and I love refactoring code. 😄

[rubenv]

First one is definitely not something we can change, even if we wanted to (I don't): compatibility matters! But you can work around this by setting a translation parameter: https://rocketeer.be/blog/2016/06/translate-params/ That should isolate you from variable name changes.

[rubenv]

Also, placeholders like {{1}} are horrible for translators as they have no semantic meaning. It helps translators massively to see {{username}}, replacing it with a number is a very bad practice.

[rdeslonde-eichleay]

Another workaround for #1 that I have used is to just put the translation around the text with context:

<translate translate-context="welcome-user">Welcome</translate> {{$ctrl.userName}}!

[rubenv]

@rdeslonde-eichleay I'd highly recommend you do not do that. Not all languages use the same word order so it might lead to very weird translations. Always put the full string up for translations.

That's the whole point of gettext: translators can move variables around and provide really good localized results.