Make text not marked for translation stick out

[graham.carlyle@…]

When changing templates to use the translation related tags, I found it quite tricky to chase down all the bits of text that needed translating. Finding *all* the text is especially important if the there will be a large turnaround time on the translations or there's a charge per set of translations.

To be more confident I'd translated everything I hacked the django src to replace translatable text with the string "XXXX" so text that wasn't marked as translatable stood out.

Index: django/utils/translation/trans_real.py
===================================================================
--- django/utils/translation/trans_real.py	(revision 10575)
+++ django/utils/translation/trans_real.py	(working copy)
@@ -83,6 +83,9 @@
     def __repr__(self):
         return "<DjangoTranslation lang:%s>" % self.__language
 
+    def ugettext(self, msg_id):
+        return u'XXXX'
+
 class DjangoTranslation23(DjangoTranslation):
     """
     Compatibility class that is only used with Python 2.3.

So maybe this might be a useful "feature" to have. Possibly a setting to make the translation return a dummy value and maybe another setting for the value, being a string or a callable (taking the msg_id).

DEBUG_I18N = True
DEBUG_I18N_TRANSLATOR = lambda(msg_id): "XXXX"

I suppose you could create a dummy po file to achieve a similar effect but I couldn't see any easy way of creating such a po file (that could be an alternative I suppose, a utility to generate such a file)

[Alex Gaynor]

Except this would cause the application to not degrade nicely in the event of a missing translation.

[Ramiro Morales]

You can already know how many and which literals from a .po file are untranslated or fuzzy without having to resort to navigate through all your site looking for 'XXXXX' text:

• Using msgfmt --statistics -o /dev/null django.po or a wrapper like: ​http://www.djangosnippets.org/snippets/986/
• Using the facilities of your text editor: poedit, the PO mode of Vim and I suspect every major progammer etxt editor have some facility for finding these literals needing work. If you are using another text editor then searching for ', fuzzy' and 'msgstr ""' could be of help

[graham.carlyle@…]

Replying to Alex:

Except this would cause the application to not degrade nicely in the event of a missing translation.

Eh? this is for debugging only

Replying to ramiro:

You can already know how many and which literals from a .po file are untranslated or fuzzy without having to resort to navigate through all your site looking for 'XXXXX' text:

Yes and that's not the problem I described in the ticket.. It was to work out which bits of text in the template that are not enclosed in one of the translation related tags.

[Malcolm Tredinnick]

Normal practice for inernationalizing an application (whether it be a Django app or anything else) is to create a dummy translation file and then write out every msgstr as the msgid with a prefix attached (e.g. via a script). No modifications are needed inside Django for that -- the script could be an external one.

Not clear at the moment whether this would be worth including in Django or not, since there's no particularly nice place for it to fit (how/if people choose to use it will be dependent on their workflow). However, if somebody comes up with a reasonable management command, it's worth looking at. It should only change a PO file for a domain specified (in the same way as makemessages and compilemessages), maybe even restricted to one particular app.

For anybody implementing this, one helping feature might be the --msgstr-prefix and --msgstr-suffix options that xgettext takes. I've used them a lot in other projects to check for i18n coverage of appropriate strings.

(Should also be noted, for anybody working on this, that not marking every string in a template is not an error. Some strings, even user-visible ones, are intentionally left in English because they are only displayed in error cases and sent back to debuggers or customer service as more information. So we shouldn't ever default to making things like that be errors.)

[Claude Paroz]

It seems podebug of Translate-Toolkit is the ideal tool for this.

​http://translate.sourceforge.net/wiki/toolkit/podebug

I suggest closing this as a wontfix.

[Jannis Leidel]

Agreed, closing.