[Mailman-Developers] Ah-HAH!

[Ron Jarrell]

I found the damn error causing tracebacks in MailList from "ValueError: list.index(x): x not in list."

I was right that it was in the languages section, because that's the only place in MailList we call
index.  I had to unravel the language support though.

While it's building the options list which will be handed off to the cgi form, it's trying
to create the "pretty" names for the languages installed on that list.  At line 352
we do

langs = self.GetAvailableLanguages()

(where self is the current MailList).  GetAvailableLanguages brute force just walks the
directory and looks for subdirs, by calling Utils.GetDirectories(self._full_path).  If there's
a subdir, it's a language.  (Which means don't be creating subdirs under lists; mailman will
think you've added a new language.  I'm thinking the template dir should be listname/templates/language
so as to avoid confusion...)

If there are no subdirs, then there are no languages.  langs is set to [].

at line 381, in the monolithic setting of the config_info['general'] block, we have:

 ('preferred_language', mm_cfg.Select,
	     (langs, map(_, map(Utils.GetLanguageDescr, langs)),
	      langs.index(self.preferred_language)), 0,
             _("Default language for this list."),
             _("All messages not related to an specific user will be displayed in this language.")),

Since self.preferred_language is forced to en on every new list, when we do the
langs.index(self.preferred_language), in this scenario, well, gosh, taking an index of something
not in the list is bad, since we're doing nothing to catch any possible exceptions...

So the short term workaround, for me, is to make sure all the lists have en installed.
Ideally the code needs to cope with a missing language cleanly.  This, I guess, makes it
more important for the update proc to forcibly install *something* in a new en directory
for any list that doesn't have one.

-Ron