Run translation after I've modified strings?

[dvagala]

I'm coming from old v1.8.0, where was the --overwriteOutdated=false option to be able to retranslate strings if the text changes.

Now I've migrated to the current version 2.2.0 and I don't understand how the caching works. When I modify some input strings, run attranslate, it just log Target is up-to-date and won't re-translate that string.

How to do it? Am I missing something?

[fkirc]

Hi,

Newer versions of attranslate do not use any caching anymore, because of the following reasons:

Most users of attranslate wanted to use --overwriteOutdated=false, because they were unable or unwilling to deal with --overwriteOutdated=true.
Important to note here is that the cache was only needed for --overwriteOutdated=true.
As a result, the complexity of the cache was no longer justified, so I removed the cache in newer versions of attranslate.
Moreover, the whole cache was too complex for users who barely even knew how to do a git commit and were barely able to commit the cache into version-control, which was another reason to get rid of the cache.

TLDR: --overwriteOutdated=false is no longer needed, since newer versions never ever overwrite outdated strings.
If --overwriteOutdated=true is still needed, then only old versions of attranslate support it.

[fkirc]

Personally, my recommendation is to never use overwriteOutdated anymore, and instead introduce a new translation-key if the meaning of a translation becomes completely outdated.

[dvagala]

Thanks for the clarification! I understand, everyone could have a slightly different use case.

I think I'll just make a pre-script that will remove the key from target files if the source text differs.

[fkirc]

Yes, a pre-script is a possible solution.

But how do you detect if the source text differs?
It was precicely the job of the cache to detect differences of source text.
But like I said, in my experience it is better to introduce new translation-keys (and delete old keys), if the meaning of a translation changes to such a big degree that all targets need to be changed.

Or alternatively, you could script something like this:

• delete source key
• run attranslate (will delete target keys)
• re-add the same source key
• run attranslate a second time (will re-create target keys with fresh translations)

[fkirc]

Also one more note about the product philosophy of attranslate:
attranslate is designed to be a simple script that can be integrated within minutes, and therefore the cache needed to be removed because it took too much time to explain what the cache was doing.
As such, customizations should be rather done with pre-scripts or post-scripts.

The market for complex system with translation-caches is already satisfied by more complex solutions like weblate, so attranslate will stick to its niche of being a simple script that needs almost zero explanations (without caches).