View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001911 | unreal | ircd | public | 2004-07-01 17:08 | 2015-07-13 22:49 |
| Reporter | hypnetric | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.3-alpha0 | ||||
| Summary | 0001911: Configurable Server Messages (transatable ircd) | ||||
| Description | It'd be nice to be able to configure IRC messages for mostly all events in the config file, instead of hard coded. | ||||
| 3rd party modules | |||||
| has duplicate | 0002292 | closed | Language files |
|
|
It's nice to use a chainsaw to attack bill gates too |
|
|
>It's nice to use a chainsaw to attack bill gates too ROFL I can probably only see one use of this: translating the IRCd (assuming that hasn't already been done :P ) |
|
|
I've been considering a method to let it use gettext, if available. That would allow translation. |
|
|
Yeah gettext can be nice (have been reading an article about it a month ago). However, we will not be making all numerics 'translatable' or something, which is usually what all these turkish/whatever guys do... This is completely against the protocol (ok, well for 98% of the numerics, thinks like cannotkick-due-to-+q could be done, but not stuff like LUSERS and the hundreds of other numerics). |
|
|
Yeah, it's hard to say which numerics would cause problems (because clients parse them). |
|
|
Well, mIRC probably doesn't have too many issues with us redefining numerics... but then again... I would definately say NOT allow redefinition of the numerics listed in RFC 1459 - these are the standard numerics, and if clients need them localized, they should translate them by hand :P . Anything not listed is _probably_ safe, but I wouldn't put gauruntees (sp?) on that :P I can definately see allowing localizing of the NOTICEs the IRCd uses :) those are definately safe since clients don't need to parse them. Unless scripts come into play... but then people can just update their scripts :P |
|
|
Ok, I changed my attitude a bit after learning a bit more about this (@numerics I mean). It seems it would be something nice for 3.3* if there's also some way for the client to choose the language / get back to the official english version (which IMO should always be available)... Then a spanish server could set spanish by default and bots/whatever could choose english etc. (I guess that will be in HANDSHAKE then ;p).. |
|
|
aqua, you'd be suprised how wrong that is ;) The reason is, all the numeric conflicts! Different IRCds use the same numeric for vastly different things. Ideally, to recognize a numeric, all you must do is check the number. But, since there are conflicts, you need to check the text too. For example, in Unreal 307 is the "is a registered nick" WHOIS message. In AustHex it is something called "SUserHost." So, to determine whether this numeric is part of a WHOIS (and therefore should be hidden if the client itself requested the /whois for internal purposes), it must check the text. So if the text is translated, you're screwed :P You'd be suprised to see how often that happens. But I do agree with Syzop, if the client requests it, then we should assume that means the client knows what it is doing. So, if it wants Spanish, we'd assume it knows how to understand the Spanish text. |
|
|
Hence why I said "probably" :P |
|
|
Please resubmit this bug if it persists on 3.2.6-7/3.3 |
|
|
this probably got closed too quickly in the closeflood ;p. Trocotronic is working on this. current focus is on gettext, but speed issues (and tech issues in general) could prevent us from using it, but it hasn't been benchmarked yet. anyway... troco, you can use this bug ;p |
|
|
Relevent mail between me and Trocotronic of March 2007 (then we both died out ;p). Hi, I see. Whether gettext is OK all depends on the speed / overhead. I don't think having calls to setlocale or other heavy functions are very realistic to do each time, meaning: that's likely to be way too much overhead, but I have not checked. In any case, there should never be any file reads caused at runtime (I mean like when sending text to a user), so: the locales will have to be in memory and should only be retrieved from MEMORY each time, not from DISK. If you could find a way to mass-read locale files in memory (like on boot and rehash), AND to find the right function that takes like.. a language/whatever as it's as argument, then it might work nicely. Alternatively: (still all in memory, not disk) if you find out that like one call to setenv(... language) followed by gettext() is still fast enough (followed by setenv.. back to "C" probably), then that too might work. Everything depends on the speed, so once you think you found the good set of functions, you'll have to do some benchmarks :) Section 10.5 of the gettext manual ( 10.5 Being a gettext grok) has some talk about 'Changing the language at runtime', you probably noticed :). Unfortunately it only talks about things we probably already know, and talks little about speed... like it doesn't mention if things will have to be read from disk (actually it almost seems to imply it will), and/or how you could do things efficiently speed-wise... :/ Perhaps you could ask on the gettext mailinglist something like: What's the best way to have fast multi-language support. A way that gettext reads all catalogs (that you want to) load in memory, and fast switching without disk-reads between languages and gettext() lookups? Regards, Bram. Trocotronic wrote: > > Hi Syzop, > > > > I was looking for gettext and I think it's a good idea. I read some > > tutorials and reference guide and it's "easy" to translate. We can make a > > "howto use gt tools" to translators and it wouldn't be a problem for them. I > > didn't have the chance to play with gt on win32 and I see a main problem: > > how can we link language to user? Can setlocale(), textdomain() and > > bindtextdomain() be initialized many times for all languages? textdomain() > > could be used before to send message but I don't know if it will be too > > slow. If not, dgettext() and dcgettext() can be another possibility. Have > > you seen catgets? There are many ways. We have to analize every one. > > > > Trocotronic. |
|
|
and now my wrist hurts again, so.. that's it ;p |
|
|
This is no goal anymore. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-07-01 17:08 | hypnetric | New Issue | |
| 2004-07-01 17:11 | syzop | Note Added: 0006833 | |
| 2004-07-01 17:13 | aquanight | Note Added: 0006834 | |
| 2004-07-02 12:01 |
|
Note Added: 0006847 | |
| 2004-07-02 12:11 | syzop | Note Added: 0006851 | |
| 2004-07-03 16:16 |
|
Note Added: 0006854 | |
| 2004-07-03 18:20 | aquanight | Note Added: 0006855 | |
| 2004-07-06 21:19 | syzop | Note Added: 0006906 | |
| 2004-07-06 23:37 |
|
Note Added: 0006912 | |
| 2004-07-06 23:39 | aquanight | Note Added: 0006913 | |
| 2007-04-27 05:47 |
|
Status | new => closed |
| 2007-04-27 05:47 |
|
Note Added: 0013840 | |
| 2007-04-27 05:47 |
|
Resolution | open => fixed |
| 2007-04-28 09:04 | syzop | Note Added: 0013911 | |
| 2007-04-28 09:04 | syzop | Status | closed => acknowledged |
| 2007-04-28 09:04 | syzop | Resolution | fixed => open |
| 2007-04-28 09:04 | syzop | Product Version | 3.2 => 3.3-alpha0 |
| 2007-04-28 09:04 | syzop | Summary | Configurable Server Messages => Configurable Server Messages (transatable ircd) |
| 2007-04-28 09:05 | syzop | Note Added: 0013912 | |
| 2007-04-28 09:05 | syzop | Note Added: 0013913 | |
| 2007-04-28 09:06 | syzop | Relationship added | has duplicate 0002292 |
| 2015-07-13 22:49 | syzop | Note Added: 0018501 | |
| 2015-07-13 22:49 | syzop | Status | acknowledged => closed |
| 2015-07-13 22:49 | syzop | Assigned To | => syzop |
| 2015-07-13 22:49 | syzop | Resolution | open => no change required |
