hello.
I am building a multi lingual site and is constantly checking the strings that need to be translated in the local.module
the problem with this is that whenever I add a new module it adds its strings to the untranslated terms, and local.module display untranslated strings randomly.
is there a way to filter strings that belong say to a certain module? or have local.module display strings sorted by module??
the reason why I want to do this, is because there are strings that i am not interested in translating because they are used mainly for administration and the admin of the site, myself, has no problem with English.
Regards, Mohammed al-shar'
Mohammed Al-shar' wrote:
Hi Mohammed!
I am building a multi lingual site and is constantly checking the strings that need to be translated in the local.module
the problem with this is that whenever I add a new module it adds its strings to the untranslated terms, and local.module display untranslated strings randomly.
is there a way to filter strings that belong say to a certain module? or have local.module display strings sorted by module??
I think that locale.module is the wrong tool for this job. If you look at the contrib cvs repository you will notice that some modules come with translations in several languages. The file format we use for distribution of such translations is the PO file format used by the GNU gettext tool.
We have a script (extractor.php) that extracts the strings that need translation from the module file. The script is delivered with the Drupal translation templates. You can run it on any module and will get a POT template. You can use this template with a PO editor such as PO edit to translate all the strings to whatever lannguage you want. And then you load a fresh copy and translate to the next language. Then, you can upload your translations directly after you installed your module. This way you won't see untranslated strings from the start.
To be fair: What I described is an ideal scenario. In reality there are some strings which are created dynamically which won't be caught by the extractor script. Also, some contributions authors don't use Drupal's translation mechanism correctly.
But I think it is a good start.
the reason why I want to do this, is because there are strings that i am not interested in translating because they are used mainly for administration and the admin of the site, myself, has no problem with English.
In the PO editor you can always chose which strings to translate.
Cheers, Gerhard
hi Gerhard!
I know about the po edit tool and I actually already use it whenever I am interested in translating a module or part of it. but I am talking about the modules that don't interest me, sometimes all I need to translate is the "dynamic strings" that drupal generates, and it could be time consuming to look through all the untranslated strings that I ignored to hunt those "dynamic strings. and I have to go through them all, because drupal seems to have no logic in organizing those strings.
let me give you an example, I want to use parts of the views module, if I install it I'll get 300 something strings and I am not interested in translated a single string of them. but they already added more than 300 untranslated strings to the local.module that will be placed in different location through the pages that display untranslated strings. see how tiresome it is now to go through this big number of strings to look for the ones that interest you?
Regards, Mohammed al-shar' ----- Original Message ----- From: "Gerhard Killesreiter" gerhard@killesreiter.de To: support@drupal.org Sent: Tuesday, October 24, 2006 1:53 AM Subject: Re: [support] local.module and filtering strings
Mohammed Al-shar' wrote:
Hi Mohammed!
I am building a multi lingual site and is constantly checking the strings that need to be translated in the local.module
the problem with this is that whenever I add a new module it adds its strings to the untranslated terms, and local.module display untranslated strings randomly.
is there a way to filter strings that belong say to a certain module? or have local.module display strings sorted by module??
I think that locale.module is the wrong tool for this job. If you look at the contrib cvs repository you will notice that some modules come with translations in several languages. The file format we use for distribution of such translations is the PO file format used by the GNU gettext tool.
We have a script (extractor.php) that extracts the strings that need translation from the module file. The script is delivered with the Drupal translation templates. You can run it on any module and will get a POT template. You can use this template with a PO editor such as PO edit to translate all the strings to whatever lannguage you want. And then you load a fresh copy and translate to the next language. Then, you can upload your translations directly after you installed your module. This way you won't see untranslated strings from the start.
To be fair: What I described is an ideal scenario. In reality there are some strings which are created dynamically which won't be caught by the extractor script. Also, some contributions authors don't use Drupal's translation mechanism correctly.
But I think it is a good start.
the reason why I want to do this, is because there are strings that i am not interested in translating because they are used mainly for administration and the admin of the site, myself, has no problem with English.
In the PO editor you can always chose which strings to translate.
Cheers, Gerhard -- [ Drupal support list | http://lists.drupal.org/ ]
On 10/23/06, Mohammed Al-shar' mohammed@atexplorer.com wrote:
location through the pages that display untranslated strings. see how tiresome it is now to go through this big number of strings to look for the ones that interest you?
You've described how the current process doesn't work very well for your use case.
Now can you describe (and maybe give patches) for a system that makes your use case easier?
Regards, Greg
hi Greg,
"You've described how the current process doesn't work very well for your use case.
Now can you describe (and maybe give patches) for a system that makes your use case easier?"
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 for a better cms, obviously. if I had the coding skills necessary for such task I would've worked on it. a great percentage of the emails sent to this list are to ask for help doing something, so I am not alone. I wasn't even sure that such a thing isn't already possible.
we all work according to our limits, no one said you have to be a coder to participate and ask questions. if it was so, please moderators, state this plainly in the discription of the mailing list.
sorry if I sounded a bit dry. but this is not the first time I witness such an attitude in this list.
Regards, Mohammed al-shar' ----- Original Message ----- From: "Greg Knaddison - GVS" Greg@GrowingVentureSolutions.com To: support@drupal.org Sent: Tuesday, October 24, 2006 7:24 AM Subject: Re: [support] local.module and filtering strings
On 10/23/06, Mohammed Al-shar' mohammed@atexplorer.com wrote:
location through the pages that display untranslated strings. see how tiresome it is now to go through this big number of strings to look for the ones that interest you?
You've described how the current process doesn't work very well for your use case.
Now can you describe (and maybe give patches) for a system that makes your use case easier?
Regards, Greg
-- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses -- [ Drupal support list | http://lists.drupal.org/ ]
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
-
Gerhard Killesreiter -
Greg Knaddison - GVS -
Mohammed Al-shar'