[support] local.module and filtering strings

[Greg Knaddison - GVS]

On 10/24/06, Mohammed Al-shar' <mohammed at atexplorer.com> wrote:
> Isn't the answer to your question very clear in my last post? I obviously
> asked if filtering the strings according to the module that generates them
> is possible. and I wasn't complaining if you got it so. we are here to work

No - it's not clear.  At least not to me.

Gerhard gave you a way to filter out the strings by module.  So I want
to know what it is about his method that isn't enough.  If the
extractor needs to give you more information about the strings (like
"show to public" vs. "shown to admin" then please state specifically
how you want the functionality to work so that you get the maximum
benefit and others can understand your vision.

To me, sorting by module inside the interface isn't a solution because
you still have the problem of a new module giving you 300 new strings
- the presentation layer is just different because it is a web UI
instead of a POT and I don't see how that makes them more manageable.
My suggestion is for an extra argument to be added to the localization
which says either generically "admin string" or "user string".  Given
Drupal's flexible permission system that wouldn't work well because a
site admin can make permissions very loose.  Another solution is to
pass in the access level that is required to see the string.  Then if
you could sort the UI by module and acess level you have actually
solved your problem.

If you can't or don't want to code then you need to have a very very
clearly stated goal in mind so that other people can see the benefit.
I'm trying to say that I don't see a clear path to the end point of
your use case so I suggest you elaborate on precisely how the module
should work which would allow others to chime in with "yeah that
sounds good" or "no, that won't work" and hopefully someone would say
"yeah, that sounds good enough to me that I'll do it".

I'm not trying to say that you have to code to contribute - there are
many who don't code or for whom code is only part of the contribution.
 But, if you want to see change then you have to state bugs and
feature requests very clearly and make a solid case for why it's an
improvement.

Regards,
Greg

-- 
Greg Knaddison | Growing Venture Solutions
Denver, CO | http://growingventuresolutions.com
Technology Solutions for Communities, Individuals, and Small Businesses