Accepting inconsistency in TxEditor changes behavior in translation

[mw-martin]

I'm not sure if this behavior is intentional, but it is not how I understood the documentation.

Say you have a txd file with English (as primary) and French cultures, and a key that intentionally only has a translation for english:

<?xml version="1.0" encoding="utf-8"?>
<!-- TxTranslation dictionary file. Use TxEditor to edit this file. http://unclassified.software/txtranslation -->
<translation xml:space="preserve">
	<culture name="en" primary="true">
		<text key="minimum" comment="The english translation works also for french">Min</text>
	</culture>
	<culture name="fr" />
</translation>

Then Tx.SetCulture("fr"); Tx.T("minimum"); would result in "Min" as intended.

The TxEditor shows a "Missing translation" as a problem for that key, so you click on that (so it gets a green checkmark) to accept the inconsistency and mark it as intentional. This results in:

<?xml version="1.0" encoding="utf-8"?>
<!-- TxTranslation dictionary file. Use TxEditor to edit this file. http://unclassified.software/txtranslation -->
<translation xml:space="preserve">
	<culture name="en" primary="true">
		<text key="minimum" comment="The english translation works also for french">Min</text>
	</culture>
	<culture name="fr">
		<text key="minimum" acceptmissing="true" />
	</culture>
</translation>

With that file, the behavior is now different, and Tx.SetCulture("fr"); Tx.T("minimum"); results in an empty string.
I expected this to only affect the behavior in the TxEditor, not the actual translation.

[mw-martin]

Hm, I guess there is no way to distinguish between "Accept the empty string as the translation" and "Accept the fallback behavior as intended" in the current file format.
I think the latter case is more frequent (e.g. when you have abbreviations that are the same for most or all of the cultures).

[ygoe]

You're right to assume that using that "accept" option in TxEditor should not have any effect on programs using the dictionary file. And it's indeed probably because now a key exists. I guess I could add a behaviour to the TxLib code to ignore XML elements when there's no text and the acceptmissing attribute is set to "true". Because you were accepting it missing when it was empty. So it should be considered empty afterwards, too, even though it's technically there.