Bug 3755 - Add configuration setting: use_language
Summary: Add configuration setting: use_language
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P3 enhancement
Target Milestone: Future
Assignee: Morten Isaksen
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-06 11:05 UTC by Morten Isaksen
Modified: 2019-08-10 14:57 UTC (History)
3 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Added use_language conf setting patch None Morten Isaksen [HasCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Morten Isaksen 2004-09-06 11:05:59 UTC 
At the moment SA uses the LANG enviroment variable to determinate the 
localization. This is a problem when you use spamd or the when the users does 
not have a shell account.

My suggestion is to add a "use_language" configuration setting, that when set 
overrides the LANG enviroment.

As far as I understand the code this is not strait forward to implement since 
the rules (and the 30_text_<lang>.cf file) is red before the userpref.
Comment 1 Justin Mason 2004-09-06 18:07:45 UTC 
I think it's a good idea.

I'm not sure how to implement it -- consider this scenario:

  - 6 translations (5 localized + en_US)
  - 700 rules
  - 70 chars per description
  - 32 bytes overhead per string in the storage hash (I'm
    guessing here, but perl is profligate with memory here)

that comes out as (6 * 700 * (70+32)) = 428400 bytes.  should we
carry that overhead in RAM for all scanning, or read it from disk
when needed?

(actually, 428k isn't a massive deal now that I think of it...)
Comment 2 Morten Isaksen 2004-09-07 13:47:27 UTC 
I am planing to implement this. I would like your input on the following idea:

- Add use_language as a $CONF_TYPE_STRING configuration setting with default
  value LANG
- In parse sub replace the $lang variable with the value of use_language if
  different from LANG.
- Move the 30_text_*.cf file from the rules directory to a seperator directory
  (eg lang/)
- Load these file after the userpref file in the init sub.

Is that OK?
Comment 3 Bob Menschel 2005-04-07 21:25:13 UTC 
Morten, your proposal sounds good to me (not a dev). Hoping you'll follow
through, I've updated the milestone to "Future" and changing assignment to you.
Comment 4 Morten Isaksen 2005-07-23 07:53:32 UTC 
Created attachment 3033 [details]
Added use_language conf setting
Comment 5 Morten Isaksen 2005-07-23 07:59:36 UTC 
(In reply to comment #3)
> Morten, your proposal sounds good to me (not a dev). Hoping you'll follow
> through, I've updated the milestone to "Future" and changing assignment to 
you. 

Forgot about this for a while...

I have implemented this now.

The patch has been submitted. In order to make this patch work a lang 
directory must be created in the rules directory and the 30_*.cf files must be 
moved to the lang directory (they need to be parsed after the user_pref file). 

It could by a good time to rename the 30_*.cf file to text_de.cf or something 
like that. I dont see any use for the number at the start any more.
Comment 6 Morten Isaksen 2005-08-16 07:09:55 UTC 
I faxed the CLA to Apache yesterday.
Comment 7 Kevin A. McGrail 2012-01-18 21:57:12 UTC 
I've updated your account to reflect your CLA was received a 6+ years later.  Is this bug still of interest because I hate to see patches submitted that just stuck in the queue :-(
Comment 8 Henrik Krohns 2019-07-30 18:58:23 UTC 
I'm not going to close this outright, but I'd like to.

How many users actually use SA localization? How many of those are not able to set environment variables? I figure this will be super minority. This bug hasn't got any comments in 14 years.

I would honestly rather remove 30_text_*.cf completely from the distribution, has someone actually updated them in 15 years??
Comment 9 Kevin A. McGrail 2019-08-10 14:57:28 UTC 
I like the idea and I think if it can be used with OK_LOCALES somehow, it might be more useful