Re: localisation in system wide daemons
Hi All!
On Fri, 2006-12-22 at 09:37 +0100, Javier Fernández-Sanguino Peña wrote:
>
> IMHO, either that software should be modified to support i18n text or the
> admin would have to choose wether he prefers to *understand* the logfile or
> to be able to parse it with automatic programs (I believe you are talking
> about tools such as logcheck or log-analysis [1][2]).
Yes, I talk about this programs.
>
> So it could be realy straightforward to convert a text mesage like this
> (from logcheck's kernel violation.d rules):
Yes, but if you try to convert all logcheck rule into all language, that
will be a lot more regular expression, and because of this log analyzing
will need a lot more time.
> Or even have logcheck use those PO files directly by introducing some tokens
> in its regexps.
I think it's may have problems. For example what about this log message:
syslog(_("This is a log message. problem='%m', severity='%s"),
severity);
What do I do if I want to hide this mesage, if severity lower or equal
to warning?
(I want to say that sometimes the log messages merged from two or more
part)
> For those logparsing programs that would not had i18n support, the user (or
> admin) would at least have the *option* to make a decission.
I think log messages (which may be sent in network, archived, read by
more than one user, etc.) wouldn't be changed in any circumvent.
Of course it's my opinion.
> Consider this situation: a user that can not even *read* english (since he
> doesn't understand the written language as he uses different script) should
> be able to weight which option is more important to him:
And every command name is translated? And every shell command too? I
don't think so.
And some log messages isn't too understandable, even if it's in
someone's native language.
For example in this log message:
2006-12-17T06:41:09+0100 fw ntpd[621]: sendto(148.6.0.1): Bad file descriptor
the good question is not that how can I translate it to Hungarian,
because it will not help. The good question is, what it cause, and how
can I avoid this.
But tho answer this an expert is more important than the exact meaning
of the message. And as Gabor said for this a stable form of log is very
important.
> a.- be able to use software that generates reports from logfiles with english
> messages, and not being able to understand the logfiles themselves and
> (probably) not the reports either (if the reporting software is not i18nised)
>
> b.- be able to read the non-english logfiles, but unable to use software to
> geenrate reports or summarise logs (until such a software is adapted to
> support non-english messages).
Hmm. It's a hard question. It's especially hard because I think that to
be a system administrator it's important to know english. And not just
because the log messages, but because the commands and documentations.
And I think an average home user never look into the logs, only if
somebody ask he to do it.
So as a conclusion, I think a.- is my answer.
Re: Template toolkit: removed functionality issue
On Dec 22, Andreas Schuldei <[EMAIL PROTECTED]> wrote: > The conservative thing to do would be to depend on the new plugin > modules. I think debian is trying to protect the user from these While the smart thing to do would be to add a versioned conflict with the packages which would be broken. User-installed packages do not matter, they are at risk of breaking anyway after every upgrade. -- ciao, Marco signature.asc Description: Digital signature
Re: Template toolkit: removed functionality issue
On Fri, Dec 22, 2006 at 08:06:00PM +0100, Andreas Schuldei wrote: > * Dominic Hargreaves ([EMAIL PROTECTED]) [061222 17:47]: > > and then upload a new libtemplate-perl reflecting upstream's changes > > with a NEWS.Debian entry explaining the change? Should libtemplate-perl > > then Recommend or Depend on the new separate plugin modules? My > > intuition would be to avoid a Depends. > > Potentially breaking working webapps is not a nice thing, though. > The conservative thing to do would be to depend on the new plugin > modules. I think debian is trying to protect the user from these > kind of suprises and should be conservative and diskspace is > cheap. You can change the depends to a recommends for lanny (or > was it larry? lenny?) later on. Really the question boils down to what sort of guarantees we are providing to people using these libraries *not* via a package in the Debian archive, though. I've already demonstrated that it is easy to simply have bugzilla add a dependency, and my thought is that anyone using the functionality not as part of a package would have had the same upgrade issue had they been installing Template Toolkit from the vanilla CPAN sources. There's only so far we can go to support software that we don't know about. I'm not arguing hard for either route, though. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Template toolkit: removed functionality issue
* Dominic Hargreaves ([EMAIL PROTECTED]) [061222 17:47]: > and then upload a new libtemplate-perl reflecting upstream's changes > with a NEWS.Debian entry explaining the change? Should libtemplate-perl > then Recommend or Depend on the new separate plugin modules? My > intuition would be to avoid a Depends. Potentially breaking working webapps is not a nice thing, though. The conservative thing to do would be to depend on the new plugin modules. I think debian is trying to protect the user from these kind of suprises and should be conservative and diskspace is cheap. You can change the depends to a recommends for lanny (or was it larry? lenny?) later on. /andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402650: ITP: mozilla-foxyproxy -- advanced proxy management tool for iceweasel
On Fri, 22 Dec 2006, Andrea Bolognani wrote: > >...< > > implemented-in::TODO (JavaScript is a missing tag although present in > > devel::lang) > The right tag is implemented-in::ecmascript, since JavaScript is a dialect > of ECMAScript. doh... it is even written ECMAScript/JavaScript on debtags interface page... how could I miss it -- Thanks a lot! and good to know ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Template toolkit: removed functionality issue
Hello, I write as someone preparing an NMU for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393311. Template Toolkit 2.15 removed a few plugin modules from the main distribution and I would like to package this new version. The plugins removed are: Template::Plugin::DBI Template::Plugin::XML Template::Plugin::GD I've checked packages depending on libtemplate-perl, and the only package that appears to use any of these plugin modules is bugzilla. Would it therefore be okay to simply package libtemplate-plugin-gd-perl, and have bugzilla depend on it (and possibly the equivalent libtemplate-plugin-dbi-perl and libtemplate-plugin-gd-perl packages), and then upload a new libtemplate-perl reflecting upstream's changes with a NEWS.Debian entry explaining the change? Should libtemplate-perl then Recommend or Depend on the new separate plugin modules? My intuition would be to avoid a Depends. Thanks, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
On Wed, Dec 20, 2006 at 05:33:18PM -0800, Steve Langasek wrote: >On Wed, Dec 20, 2006 at 03:43:55PM -0500, Joey Hess wrote: >> > I'm sure they're, so can't we go for a new multiarch containing hppa >> > and ia64 only or even i386, hppa and ia64 ? > >> Hmm, keeping i386 on it is an interesting idea. Or it could have alpha, >> hppa, and ia64, for the big/old/weird/64 bit iron multiarch cd. :-) > >I was just thinking that alpha/hppa/ia64 would be an interesting "HP-themed" >multiarch CD. Sounds like this would be fun to work on. :) I have no idea >if the CD booting for these archs can coexist naturally, though. Bad news I'm afraid. I've worked through the mkisofs boot code again, and I get: alpha:Writing alpha boot descriptor at extent 0 arm: No boot sector amd64:Writing el torito VD sector at extent 17 hppa: Writing hppa boot descriptor at extent 0 i386: Writing el torito VD sector at extent 17 ia64: Writing el torito VD sector at extent 17 m68k: Writing hfs descriptor at extent 0 mips: Writing mips boot descriptor at extent 0 mipsel: Writing mipsel boot descriptor at extent 0 powerpc: Writing hfs descriptor at extent 0 s390: No boot sector sparc:Writing sun boot descriptor at extent 0 Writing genboot sector at extent 1 I'm looking further to see if it's at all possible to get (e.g.) hppa and alpha to live in the same boot sector, but it's really not likely. >(Does weird iron contain strange quarks in its nuclei?) *grin* -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? signature.asc Description: Digital signature
Documentation CD (was Re: Bits from the debian-cd team; more CD/DVDs being built regularly)
On Fri, Dec 22, 2006 at 01:21:01PM +0100, Holger Levsen wrote: > Hi, > > On Friday 22 December 2006 11:07, Javier Fernández-Sanguino Peña wrote: > > I'm not sure if this is done (I assume it's not) but I would really like > > the DVDs / CDs to have a 'documentation media' which could be used to read > > documentation without having to install the system. > > I like the idea. Should we file a bug against debian-cd so this doesnt get > lost? Bug submitted In the past I tried to tackle this through ftp.debian.org, since the Debian CD scripts would mirror all the content under /debian/doc/ in the mirrors to the '/doc/' directory in the CDs. Unfortunately, the Ftp masters have ignored #172482 completely. Currently the only way to put stuff under that directory si through BYHAND processing [1] which is a p* in the a* (for them and for package maintainers, just look at http://ftp-master.debian.org/new.html and check out the status of doc-debian). Regards Javier [1] Which, incidentally, means that documentation needs to be provided in a Debian package which is not always the case and also introduces a gap between publishing in the website (through CVS, which is automatically build) to publishing in the ftp site (need to make a package from the CVS sources, sign and upload). signature.asc Description: Digital signature
Re: localisation in system wide daemons
Hi, * Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2006-12-22 14:43]: > On Wed, Nov 29, 2006 at 07:33:20PM +0100, Nico Golde wrote: > > Adam Cécile reported #400719[0] to the fetchmail package. [...] > > Fetchmail currently does, we are not calling it with > > LC_MESSAGES=C or something similar. > > But are you sourcing the system's locale or are you depending on the locale > of the user *starting* fetchmail? No > > I can't find anything about this in the policy but to me it > > doesnt make sense to use a locale if you dont want it for > > some programs. > > Why would you *not* want a locale? If the program has l10n support and it > provides messages (even in a non-interactive way) there's chances some users > will benefit from the translated messages. Yes thats also my opinion about it. > > Since it would be also possible to adjust the settings with > > LC_ALL=C in /etc/default/fetchmail I just closed the bug but > > reopened it now cause I want to hear some other opinions. > > What do you think what is the best way here? > > I suggest you introduce a variable in /etc/default/fetchmail named > "USE_SYSTEM_LOCALE" and do that (source the system locale if it exists) if > set to 'Y'. That's better than forcing users to introduce the system locale > in every /etc/default/XXX file and it also makes it easier to switch a > system's locale (no need to touch in many different /etc/default/ files, just > the 'locale' itself). Set the default to whatever you feel comfortable with. Thats a good idea even if the parsing in init would be far more complex. The uncommented LC_ALL=C in fetchmail.default is just a workaround but could be better. Thanks! Nico -- Nico Golde - http://www.ngolde.de JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF Forget about that mouse with 3/4/5 buttons, gimme a keyboard with 103/104/105 keys! pgpwNs6ElqEH8.pgp Description: PGP signature
Re: localisation in system wide daemons
On Fri, Dec 22, 2006 at 09:37:35AM +0100, Javier Fernández-Sanguino Peńa wrote: > b.- be able to read the non-english logfiles, Btw.: you rarely _read_ logfiles, because most of the time they are just too terse (unless you already know what they mean, but then it is no longer important what language do they use). What you do instead is looking up the message in the documentation (or in Google), and reading the description _there_. Localized log messages make this a lot harder to do. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: localisation in system wide daemons
On Fri, Dec 22, 2006 at 09:37:35AM +0100, Javier Fernández-Sanguino Peńa wrote: > In any case, it would not be too difficult to adjust programas that parse > logs to be able to parse translated messages. Take in account that all > translated text messages would be available in a message catalog (typically a > PO file). Well, if you already have all messages in a catalog, why don't you translate the logs on the _viewing_ side? - No need to bloat the daemon's code - No need to fear from fresh new locale-related bugs in a lot of programs running as root - You do not loose searchability via Google - If you fire the previous sysadmin who likes to read log files in some arcane language you still have a chance the next admin can read the logs too - In case of network-related messages, you may simply have no other option since the real error message is generated by a remote process you have no control over Btw. googleability IMHO is quite an important reason: most of the time if you encounter a cryptic log message the best option is to cut&paste it into a google search and look at the results. With localized log messages that would never work so you take away the chance from the poor sysadmin to find out the meaning of the message. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
Hi, On Friday 22 December 2006 11:07, Javier Fernández-Sanguino Peña wrote: > I'm not sure if this is done (I assume it's not) but I would really like > the DVDs / CDs to have a 'documentation media' which could be used to read > documentation without having to install the system. I like the idea. Should we file a bug against debian-cd so this doesnt get lost? regards, Holger pgpNWU5aVtlI2.pgp Description: PGP signature
Re: Bug#402650: ITP: mozilla-foxyproxy -- advanced proxy management tool for iceweasel
On Thu, 21 Dec 2006 10:43:58 -0500 Yaroslav Halchenko <[EMAIL PROTECTED]> wrote: > I've decided to go with no prefix, since mozilla- prefix is a trademark > and point of having it nowadays is quite absent. > > So now the package is simply "foxyproxy". I will tag it > accordingly: > > implemented-in::TODO (JavaScript is a missing tag although present in > devel::lang) The right tag is implemented-in::ecmascript, since JavaScript is a dialect of ECMAScript. -- KiyuKo Resistance is futile, you will be garbage collected. pgp21Uev3nT7k.pgp Description: PGP signature
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
On Wed, Dec 20, 2006 at 06:29:04PM +, Steve McIntyre wrote:
> I'm still expecting to add Live CDs to the list here before we
> release. Otherwise, I think we're about set. If there's anything else
> you'd like us to do or anything you'd like to ask about, please reply
> to this mail - note the Reply-To to the debian-cd list.
I'm not sure if this is done (I assume it's not) but I would really like the
DVDs / CDs to have a 'documentation media' which could be used to read
documentation without having to install the system. That documentation media
would contain both the english and available translations of:
- The Release Notes
- The Installation Guide
- The Refence Guide
- The User Guide
- The Project History
- The FAQ
- The Securing Debian Manual
- The Reference Card
- The Quick Reference
- The APT Howto
Content could be extracted (in an automatic way) from both the website [1]
and/or from the Debian packages providing them [2].
By providing all that content in easily printable format it would make it
easier for users that do not have good broadband access and have not yet
installed Debian to go through or print those manuals before even starting
installation.
Having all that content in one place makes it more easier for users to find
and take profit of (you'll see below that the document to package mapping is
not at all evident for a novice user).
Just my wishlist :)
Javier
[1] Some of these are available under http://www.debian.org/doc/manuals/, or,
more
precisely, from /org/www.debian.org/www/doc/manuals , and the
release-specific info is at http://www.debian.org/releases/etch/
(/org/www.debian.org/www/releases/etch)
The Reference Card is at http://people.debian.org/~debacle/refcard/
[2] By extracing all of /usr/share/doc/${package} to the CD.
The FAQ = doc-debian
The Installation Guide = installation-guide-XXX
The Refence Guide = debian-reference-XX
The Quick Refence = quick-reference-XX
The Project History =
The APT HOWTO = apt-howto-XX
The Securing Debian Manual = harden-doc
signature.asc
Description: Digital signature
Re: localisation in system wide daemons
On Fri, Dec 22, 2006 at 08:12:52AM +0100, SZALAY Attila wrote:
> > Why would you *not* want a locale? If the program has l10n support and it
> > provides messages (even in a non-interactive way) there's chances some users
> > will benefit from the translated messages.
>
> In log files, localized messages may hurt more, than what gain with it.
>
> For example some (semi)automatic log analyzing programs couldn't (and I
> think don't want to) handle localized log messages.
IMHO, either that software should be modified to support i18n text or the
admin would have to choose wether he prefers to *understand* the logfile or
to be able to parse it with automatic programs (I believe you are talking
about tools such as logcheck or log-analysis [1][2]).
In any case, it would not be too difficult to adjust programas that parse
logs to be able to parse translated messages. Take in account that all
translated text messages would be available in a message catalog (typically a
PO file).
So it could be realy straightforward to convert a text mesage like this
(from logcheck's kernel violation.d rules):
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: [[:alnum:]]+: media error \(bad
sector\): status=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
to the Spanish equivalent of:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: [[:alnum:]]+: error en el medio
\(sector defectuoso\): estado=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
if the kernel's Spanish PO file has something like:
msgstr "media error (bad sector): status="
msgstr "error en el medio (sector defectuoso): estado="
Or even have logcheck use those PO files directly by introducing some tokens
in its regexps.
For those logparsing programs that would not had i18n support, the user (or
admin) would at least have the *option* to make a decission.
Consider this situation: a user that can not even *read* english (since he
doesn't understand the written language as he uses different script) should
be able to weight which option is more important to him:
a.- be able to use software that generates reports from logfiles with english
messages, and not being able to understand the logfiles themselves and
(probably) not the reports either (if the reporting software is not i18nised)
b.- be able to read the non-english logfiles, but unable to use software to
geenrate reports or summarise logs (until such a software is adapted to
support non-english messages).
What would you chose?
Regards
Javier
[1] There is other more domain-specific log analysis tools (for webservers,
firewalls and mail servers) in Debian but many of that software users
logfiles in a standarised (or propietary) format that is not (typically?
easily?) parseable by humans.
[2] Or Sawmill (but, even if it's a really good and cheap log analysis tool
it still is not free and, consequently, out of our scope)
signature.asc
Description: Digital signature
Achat entreprise
Title: Achat entreprise Ce message est au format HTML. Si vous ne parvenez pas à le lire, cliquez ici.Offre réservée exclusivement aux entreprises.Conformément à la Loi Informatique et Libertés parue au Journal Officiel du 6 janvier 1978, vous disposez d'un droit d'accès, de rectification, et d'opposition aux données personnelles vous concernant. Pour ne plus recevoir d'informations de notre part, Cliquez ici
