Locale subset module motivation: remove, hide, get rid of non-public UI strings

Background:

http://hojtsy.hu/blog/2007-oct-10/comparison-your-localization-options-drupal-5-and-6

Doing the World Social Forum site right now has brought up two questions for me:

First, is there a way to tell either the translation interface or a PO export to ignore all strings in /admin pages?

The use case for this is you have Drupal core translated, but then you add contributed modules and some custom strings get thrown in there, which you have to hand off to various teams to translate-- but mixed in are hundreds or thousands of contributed module strings which only site administrators will see, and for most multilingual sites these might as well stay in English.

Gabor Hojtsy wrote back:

admin pages, sharing and English language code
No, unfortunately we don't know what ends up on /admin pages. By looking at the module code, even a human cannot tell what will end up on admin pages, let alone a machine. There is no way we can tell whether forms, altered forms, blocks, etc. display only on an admin page, or elsewhere too. Drupal reuses functions, form fragments, etc extensively. We can only tell what is used in the installer just because it needs to be marked explicitly with st() or $t() - which is not a clean solution either.

1. The I10n client [correction: l10n client] certainly helps with the goal of translating only "user-visible" strings, but lets keep an eye on the admin separation possibility-- I understand there are attempts to split up modules by admin sections (which don't have to be loaded for ordinary users), localization could piggy-back on this.

Commenting later on another localization-related post:

Translating what we care about

For World Social Forum 2008 - http://wsf2008.net/ - we have tried to cut down on the number of 11,000 strings or so that we ask volunteer translators to translate into a dozen languages.

In short, we have tried to remove the administrative strings, which we don't care if they are English only.

I created a module to aid this by taking an import of 'unwanted' strings and allowing exports of languages without these strings. This is kept track of simply with a table of lid numbers, so I can see several ways to expose this to a user interface to make it easier for administrators to keep checking off "no, I don't care about that string either." (The first cut in this case was done by going through the whole file and cutting and pasting out what was not going to be seen by regular site participants, and importing that file into what we're calling the 'locale_subset' module. Further strings can be added by this method, but as I get to the point of looking at more sophisticated user interfaces for this functionality to let translators ignore strings, I need ask how this might fit into the tools you keep expanding and improving.)

Should I commit this as a new module, or is there already overlap with the work you are doing, or do you think I should try submitting it as patches to one of the localization-related modules anyway?

Thank you!

Submitted by Benjamin Melançon (not verified) on Tue, 12/18/2007 - 03:10.

Gábor replied:

hm

We need to think about where will this fit. I know that in several use cases, not translating the admin interface become a goal, but it is also not so easy because of string overlaps between user facing pages and admin pages. If you display an admin page in a certain language, it might be half translated, so you need to ensure that the admin page is displayed in English all around.

Also, for Drupal translations themselfs, the goal is to have Drupal fully localized for "foreign" languages (like mine :), so there is less of a focus on such a tool.

Anyway, it would be great to identify where such a tool would fit. Please send me the module code as a first step, so we can talk about it more, and review the approach taken. Thanks!

Resolution

http://data.agaric.com/sites/default/files/raw_files/zing_auction_47_v3-beta.zip