moz2po - strangeness when label entity is marked DONT_TRANSLATE and accesskey is not about translate

[davidfraser]

This is still reproducible with translate toolkit 0.8rc4, and
editor/ui/chrome/composer/editorPrefsOverlay.dtd in Firefox 1.5
I’ve written a simple test but it seems the problem relates to the merging of
accesskey and label and that fails to catch it. will try update the test.

[davidfraser]

Actually looking more closely the problem here is that DONT_TRANSLATE is
detected and so the convertor automatically removes the entity that should not
be translated from the po file…
However because there is a related access key, the conversion error was given.
These conversion errors are no longer produced.
It is a bit strange however to have the accesskey produced when there is no
label because of the DONT_TRANSLATE error.

I’m not sure what the right thing to do is here – we could retain the marking
DONT_TRANSLATE but still include the string in the po file – perhaps if this was
still detectable we could raise warnings if the string is translated in po2moz.

It seems strange to mark “Mail & Newsgroups” as DONT_TRANSLATE for example, so
some of this should be checked on the mozilla lists

Updated the summary; lowering priority for now, but this needs a think through…

[davidfraser]

We have a test that reproduces removing DONT_TRANSLATE elements, and caters for
the fact that we won’t remove corresponding ACCESS_KEY elements.
If we want to change this behaviour at some point we should change the test to
reflect that, but in the mean time marking this as LATER

[dwaynebailey]

\ Bug #99 has been marked as a duplicate of this bug. *

[dwaynebailey]

The problem with this bug is that its confusing for translators.

The correct approach might be to insist that the .accesskey is also in the
DONT_TRANSLATE header.

I think we need to fix this in at least 0.9