On 10/24/06, Mohammed Al-shar' mohammed@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