[BlueOnyx:08566] Re: Multi-language-format in many Contril Pages, on BX all version
mstauber at blueonyx.it
Thu Sep 22 21:01:34 PET 2011
Hi Eiji Hamano,
> 1. Recently the contents "software updates" were all rewritten
> in the fixed English character format by you.
Yes, because our Japanese translation of that module was broken. But thanks to
your help we could fix that, as you submitted an updated "base-swupdate.po" in
> It was multi-language-format for a long time, since Cobalt 550 !
Like said: Our ja/swupdate.po was broken somehow. Apparently it once had been
edited with an editor that didn't support Japanese. You know how easy those
files can break if you edit them with the wrong editor. It wasn't clear when
it broke, nor if we still had a good copy somewhere in SVN. Especially
considering that many strings had been added in between. So the old
translation (if we still had any) was probably no good. But like already said:
Thanks to your help we now have a good copy again and it'll be released as
update over the weekend.
> 2. I bought AV-SPAM5 with solarspeed.net in 2009.
> But recently the pages of AV-SPAM5 also changed
> from multi-language-format to fixed English character format.
> Is it related with you?
All my PKGs come with English language files only. Even though I am German, I
don't even include a German translation. Now if someone said: "Hey, here is a
translation, please include it", then I certainly would.
> 3. BlueOnyx News: Is there any feeling of adding a switch function?
> Please tell me the present idea.
Eiji, is this really *such* a big issue? Goddammit. It's a new page with the
newsfeed from the BlueOnyx.it website - which is only available in English
anyway, as *that* is the common language between us BlueOnyx users and coders.
Only the siteAdmin can see this page and nobody else. Although there are now
15742 BlueOnyx servers out there, you're the only one who is vehemently
outspoken against this new feature. May I ask why? And what's the problem
Let me just tell you what would be needed to make it configureable:
The file /usr/sausalito/ui/menu/base/swupdate/rssnews.xml would need to be
edited to set the line '<access require="systemAdministrator"/>' to a new
capability group that's not even there yet and which isn't assigned to anyone.
Adding new capability groups has the tendency to break things left and right
if not done carefully. So I'd rather not do that.
So I'd need to juggle in a new capability group. That's half an hour of work
and like an hour of testing just to make sure that nothing else breaks on the
Then I'd need to modify a schema file to add a new CODB database field for
storing the data if the "BlueOnyx News" menu item is visible or not. Then I'd
have to add a GUI page for the switch and another page that parses the data
and stuffs it into CODB. Next a Perl handler needs to be created to handle the
editing of /usr/sausalito/ui/menu/base/swupdate/rssnews.xml
Finally the conf file needs to be updated, so that on changes of the CODB
database field for "BlueOnyx News" the hander does its magic.
Short of adding a new capability group, I could instead let the handler wrap
or unwrap the XML data in /usr/sausalito/ui/menu/base/swupdate/rssnews.xml
into comments by dynamically rewriting it. But that will break some things
hard, as comments in the XML files are not supported and will generate display
problems. So instead the content of this file must be dynamically added or or
removed. However: The next drawback is that this would require a CCEd restart
and Admserv restart to take effect. Which we can't do dynamically from within
the GUI without beaking other things, too.
So all in all we're looking at upwards of two hours of coding and testing to
do it right. No, most likely more than that. *Just* to make it possible to
entirely disable something that 99.99% of our users either find useful, or
don't find any reasons to complain about.
So let me ask you again: Why? Why is this such a big deal?
Quite honestly: I'd rather spend that time doing something useful instead.
Like finding out why Sendmail isn't restarted after adding or removing a user.
THAT would be something really useful.
Here is a suggestion for you:
/bin/rm -f /usr/sausalito/ui/menu/base/swupdate/rssnews.xml
You can even put it in a cronjob in /etc/cron.daily/ that runs after the daily
YUM-update, so that even if a new base-swupdate is released, it'll
automatically remove the XML file that makes the "BlueOnyx News" appear in the
GUI. The default start page of the GUI will then revert back to what it was
Now how's that for a solution?
With best regards
More information about the Blueonyx