Change of SM default_charset to UTF-8
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
Change of SM default_charset to UTF-8
by Miro Konecny
::
Rate this Message:
Hi all,
seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18, I'd like to propose to switch the SM's default_charset to UTF-8 as well. The definition for it resides in config/config_default.php and I suggest to modify it as follows: ------------------ /** * Default Charset * * This option controls what character set is used when sending mail * and when sending HTML to the browser. By default it's set to 'utf-8', * which ensures that mail written in any charset could be handled correctly. * * This option is active *ONLY* when default language is en_US. In other * cases SquirrelMail uses charset that depends on default language. * See $squirrelmail_default_language * * If you're seeing any strange problems with UTF-8, you might try to set * the default charset to 'iso-8859-1'. * @global string $default_charset */ $default_charset = 'utf-8'; ---------------------- The above change will have zero impact on existing installations, since this template file is used just for fetching defaults during first SM installation. Anyway, I do belive that setting this to UTF-8 is a good way to express our common preference for UTF-8 and initiate migration towards it. What do you think? Regards, MK ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Fredrik Jervfors-4
::
Rate this Message:
> Hi all,
> > seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18, > I'd like to propose to switch the SM's default_charset to UTF-8 as well. > > The definition for it resides in config/config_default.php and I suggest > to modify it as follows: > > ------------------ > > /** > * Default Charset > * > * This option controls what character set is used when sending mail > * and when sending HTML to the browser. By default it's set to 'utf-8', > * which ensures that mail written in any charset could be handled > correctly. * > * This option is active *ONLY* when default language is en_US. In other > * cases SquirrelMail uses charset that depends on default language. > * See $squirrelmail_default_language > * > * If you're seeing any strange problems with UTF-8, you might try to set > * the default charset to 'iso-8859-1'. > * @global string $default_charset > */ > $default_charset = 'utf-8'; > > ---------------------- > > The above change will have zero impact on existing installations, since > this template file is used just for fetching defaults during first SM > installation. Anyway, I do belive that setting this to UTF-8 is a good way > to express our common preference for UTF-8 and initiate migration towards > it. > > What do you think? Personally I like it, Miro. It has been discussed before and it can certainly be done in the development version. As for 1.4.18 I'm not sure. I'd like to have some testing time in 1.5.2 SVN first. What do the rest of the list think? If I see no objections I'll go ahead and commit your suggested change to 1.5.2. Sincerely, Fredrik ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Tomas Drbohlav
::
Rate this Message:
Fredrik Jervfors napsal(a):
>> Hi all, >> >> seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18, >> I'd like to propose to switch the SM's default_charset to UTF-8 as well. >> >> The definition for it resides in config/config_default.php and I suggest >> to modify it as follows: >> >> ------------------ >> >> /** >> * Default Charset >> * >> * This option controls what character set is used when sending mail >> * and when sending HTML to the browser. By default it's set to 'utf-8', >> * which ensures that mail written in any charset could be handled >> correctly. * >> * This option is active *ONLY* when default language is en_US. In other >> * cases SquirrelMail uses charset that depends on default language. >> * See $squirrelmail_default_language >> * >> * If you're seeing any strange problems with UTF-8, you might try to set >> * the default charset to 'iso-8859-1'. >> * @global string $default_charset >> */ >> $default_charset = 'utf-8'; >> >> ---------------------- >> >> The above change will have zero impact on existing installations, since >> this template file is used just for fetching defaults during first SM >> installation. Anyway, I do belive that setting this to UTF-8 is a good way >> to express our common preference for UTF-8 and initiate migration towards >> it. >> >> What do you think? > > Personally I like it, Miro. It has been discussed before and it can > certainly be done in the development version. As for 1.4.18 I'm not sure. > I'd like to have some testing time in 1.5.2 SVN first. > > What do the rest of the list think? If I see no objections I'll go ahead > and commit your suggested change to 1.5.2. I would certainly vote for Miro's proposal. If you plan to test it in 1.5.2, which I think is wise, I do not see any reason to wait. Bye, Drb ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Paul Lesniewski
::
Rate this Message:
On Sat, May 2, 2009 at 7:24 AM, Fredrik Jervfors
<jervfors@...> wrote: >> Hi all, >> >> seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18, >> I'd like to propose to switch the SM's default_charset to UTF-8 as well. >> >> The definition for it resides in config/config_default.php and I suggest >> to modify it as follows: >> >> ------------------ >> >> /** >> * Default Charset >> * >> * This option controls what character set is used when sending mail >> * and when sending HTML to the browser. By default it's set to 'utf-8', >> * which ensures that mail written in any charset could be handled >> correctly. * >> * This option is active *ONLY* when default language is en_US. In other >> * cases SquirrelMail uses charset that depends on default language. >> * See $squirrelmail_default_language >> * >> * If you're seeing any strange problems with UTF-8, you might try to set >> * the default charset to 'iso-8859-1'. >> * @global string $default_charset >> */ >> $default_charset = 'utf-8'; >> >> ---------------------- >> >> The above change will have zero impact on existing installations, since >> this template file is used just for fetching defaults during first SM >> installation. Anyway, I do belive that setting this to UTF-8 is a good way >> to express our common preference for UTF-8 and initiate migration towards >> it. >> >> What do you think? > > Personally I like it, Miro. It has been discussed before and it can > certainly be done in the development version. As for 1.4.18 I'm not sure. > I'd like to have some testing time in 1.5.2 SVN first. > > What do the rest of the list think? If I see no objections I'll go ahead > and commit your suggested change to 1.5.2. My previous suggestion was to turn 1.5.3 into UTF-only. Leave 1.5.2 as-is and make the full change in 1.5.3 (not just default charset). ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
|
|
|
Re: Change of SM default_charset to UTF-8
by Bugzilla from nice@titanic.nyme.hu
::
Rate this Message:
On 2009. május 2. 16.24.33 Fredrik Jervfors wrote:
> > Hi all, > > > > seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18, > > I'd like to propose to switch the SM's default_charset to UTF-8 as well. > > > > The definition for it resides in config/config_default.php and I suggest > > to modify it as follows: > > > > ------------------ > > > > /** > > * Default Charset > > * > > * This option controls what character set is used when sending mail > > * and when sending HTML to the browser. By default it's set to 'utf-8', > > * which ensures that mail written in any charset could be handled > > correctly. * > > * This option is active *ONLY* when default language is en_US. In other > > * cases SquirrelMail uses charset that depends on default language. > > * See $squirrelmail_default_language > > * > > * If you're seeing any strange problems with UTF-8, you might try to set > > * the default charset to 'iso-8859-1'. > > * @global string $default_charset > > */ > > $default_charset = 'utf-8'; > > > > ---------------------- > > > > The above change will have zero impact on existing installations, since > > this template file is used just for fetching defaults during first SM > > installation. Anyway, I do belive that setting this to UTF-8 is a good > > way to express our common preference for UTF-8 and initiate migration > > towards it. > > > > What do you think? > > Personally I like it, Miro. It has been discussed before and it can > certainly be done in the development version. As for 1.4.18 I'm not sure. > I'd like to have some testing time in 1.5.2 SVN first. > > What do the rest of the list think? If I see no objections I'll go ahead > and commit your suggested change to 1.5.2. Dear all! My experiences are the following: -Since the .mo files contain charset information, it's probably not too dangerous to convert these files to any charset (utf-8, for example). (However, I observed the change_pass plugint to be confused by the LOCALE value of the language, hence handling its .mo file's charset incorrectly.) -Mails, themselves (if they are correcly composed) also contain the necessary encoding information, so SM is capable to display any mail running with any charset setting (by the &#N; HTML mechanism). -User data (username, password, .pref files and similar databases) doesn't contain charset information, and my suspicion is that it's unconditionally handled according to the current language's CHARSET value. I think this means that when you change a language's charset during a version change, all the user data containing non-english characters will become unusable. Names in addressbook, the user's own name etc. has to be converted, but it's even worse that passwords containing accentuated caracters will also become invalid, so the sysadmin and the user has to change it cooperatively! I think, changing a language's charset to utf-8 is dangerous because of this, but changing only the default_charset may be safe since english language users don't have too much accentuated characters amongst their user data (maybe some french, german, spaninsh, scandinaivian names in their address books, which have to be converted after changing the default charset). I think it would be more useful for non-english users to enable lossy_encoding somehow, since it makes possible to correclty answer utf-8 encoded (but not foreign language) messages. Instead of switching every language to utf-8, I would suggest to enable system admins to set the charset for the currently used language, not just the default_charset, and in addition, sysadmins should be warned that changing this value on an existing installatiin may make it necessary to convert all user data. Sincerely, Tamás ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Bugzilla from petr.hroudny@gmail.com
::
Rate this Message:
2009/5/4 Németh Tamás <nice@...>:
> Instead of switching every language to utf-8, I would suggest to enable system > admins to set the charset for the currently used language, not just the > default_charset, This is totally impossible - you need to convert all locales, all helpfiles and modify functions/i18n.php for that. Translated strings in e.g. latin-2 charset can't be properly displayed in latin-1 and vice versa. That's why default_charset can only be configured with English, where all strings are plain 7-bit ASCII. Your only choices are: 1. broken emails, or 2. UTF-8. There's no third option, sorry. Even lossy_encoding won't help - try replying to russian email and you'll get a screen full of ?????????. To sum up - the sooner we switch to UTF-8, the better. Any modern webmail is doing exactly that. BTW, Fedora SM packages are converted to UTF-8 for years and known to work fine. My suggestion for 1.4.18: let's try to release two versions: legacy and utf-8 This way anyone could choose. No extra work is required, utf-8 version could be autogenerated by a script. Petr ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Bugzilla from nice@titanic.nyme.hu
::
Rate this Message:
I'm just and user, not a developer, so I admit that you know it better, but:
On 2009. május 4. 15.29.35 Petr Hroudný wrote: > 2009/5/4 Németh Tamás <nice@...>: > > Instead of switching every language to utf-8, I would suggest to enable > > system admins to set the charset for the currently used language, not > > just the default_charset, > > This is totally impossible - you need to convert all locales, all > helpfiles and modify > functions/i18n.php for that. Translated strings in e.g. latin-2 charset > can't be properly displayed in latin-1 and vice versa. That's why > default_charset can only be configured with English, where all strings are > plain 7-bit ASCII. According to my observations, locale files contain charset information, so SquirrelMail (or php behind the scenes) can do a charset translation on the fly. For example, I created utf-8 .mo files, and simply copied them into a plain ISO-8859-2 SM 1.4.17 installation, and all the messages were diplayed correctly. In addition to this SM can display even chinese characters (in mails) on an ISO-8859-2 installation, since the mails also do contain charset information, and characters outside your charset are inserted (by or php behind the scenes, I don't know) into the generated HTML page in a &#N; form where N is the unicode code point. The only problem I observed was, that I was unable to answer other messages than the ones composed in the same charset as mine, however lossy_encoding provides a PARTIAL solution for this problem. > Your only choices are: > 1. broken emails, or > 2. UTF-8. > > There's no third option, sorry. Even lossy_encoding won't help - try > replying to russian email and you'll get a screen full of ?????????. Yes, I know, but you would be able to correctly reply mails which are utf-8 encoded, but doesn't contain any character not in you charset, and this wold be a big advantage. > To sum up - the sooner we switch to UTF-8, the better. Any modern webmail > is doing exactly that. BTW, Fedora SM packages are converted to UTF-8 for > years and known to work fine. You're right but It can be painful to change charset on an existing installation, as I've explained before. Regards, Tamás ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Bugzilla from petr.hroudny@gmail.com
::
Rate this Message:
2009/5/4 Németh Tamás <nice@...>:
> According to my observations, locale files contain charset information, so > SquirrelMail (or php behind the scenes) can do a charset translation on the > fly. For example, I created utf-8 .mo files, and simply copied them into a > plain ISO-8859-2 SM 1.4.17 installation, and all the messages were diplayed > correctly. Have you also recompiled the .po files? If not, your SM was still using .po files from the ISO-8859-2 installation. Also have you copied the utf-8 help files and tried to click on Help? > The only problem I observed was, that I was > unable to answer other messages than the ones composed in the same charset as > mine Yes, pure display is possible, but all operations (Reply, Forward) fail. So indeed, you can see everyone's message correctly, but your outgoing messages are broken. > Yes, I know, but you would be able to correctly reply mails which are utf-8 > encoded, but doesn't contain any character not in you charset, and this wold > be a big advantage. Still not a decent solution. You get a mail from outside of CE (latin-2) region and your reply gets broken. It's really not nice to call your email recipient Bj?rn. > You're right but It can be painful to change charset on an existing > installation, as I've explained before. It's still not clear whether this is not just your local problem. And if it proves to be true, then it's one more argument for switching to UTF-8. Imagine a user chooses English initially and then decides to change to Hungarian - if you're right, his password will get broken as well as all prefs, addressbooks etc. Petr ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
Re: Change of SM default_charset to UTF-8
by Bugzilla from nice@titanic.nyme.hu
::
Rate this Message:
On 2009. május 4. 17.09.57 Petr Hroudný wrote:
> 2009/5/4 Németh Tamás <nice@...>: > > According to my observations, locale files contain charset information, > > so SquirrelMail (or php behind the scenes) can do a charset translation > > on the fly. For example, I created utf-8 .mo files, and simply copied > > them into a plain ISO-8859-2 SM 1.4.17 installation, and all the messages > > were diplayed correctly. > > Have you also recompiled the .po files? If not, your SM was still using .po > files from the ISO-8859-2 installation. Also have you copied the utf-8 help > files and tried to click on Help? I've definitely recompiled them. Moreover, there were no .po files on that server, only the newly compiled .mo files. I've even restarted the entire server, and ran it with iso-8859-2 settings and utf-8 encoded .mo files. However, I haven't tried the help files, since there are no hungarian help files :( > > Yes, I know, but you would be able to correctly reply mails which are > > utf-8 encoded, but doesn't contain any character not in you charset, and > > this wold be a big advantage. > > Still not a decent solution. You get a mail from outside of CE > (latin-2) region and > your reply gets broken. It's really not nice to call your email recipient > Bj?rn. True, but my users get lots of utf-8 encoded mails in hungarian. Maybe more than in iso-8859-2. And of course most of the messages are in hungarian, so enabling lossy_encoding in this scenario wold help a lot (I did it for myself, but there are many sysadmins out there with similar problems). > > You're right but It can be painful to change charset on an existing > > installation, as I've explained before. > > It's still not clear whether this is not just your local problem. And if > it proves to be true, then it's one more argument for switching to UTF-8. > Imagine a user chooses English initially and then decides to change > to Hungarian - if you're right, his password will get broken as well as > all prefs, addressbooks etc. Only it the charset is also changing together with the language AND he/she uses accentuated letters in user data (which is common outside of the english language world, I assume). Tamás ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
|
|
|
|
|
Re: Change of SM default_charset to UTF-8
by Bugzilla from nice@titanic.nyme.hu
::
Rate this Message:
On 2009. május 4. 19.09.14 Németh Tamás wrote:
> On 2009. május 4. 17.09.57 Petr Hroudný wrote: > > 2009/5/4 Németh Tamás <nice@...>: > > > According to my observations, locale files contain charset information, > > > so SquirrelMail (or php behind the scenes) can do a charset translation > > > on the fly. For example, I created utf-8 .mo files, and simply copied > > > them into a plain ISO-8859-2 SM 1.4.17 installation, and all the > > > messages were diplayed correctly. > > > > Have you also recompiled the .po files? If not, your SM was still using > > .po files from the ISO-8859-2 installation. Also have you copied the > > utf-8 help files and tried to click on Help? > > I've definitely recompiled them. Moreover, there were no .po files on that > server, only the newly compiled .mo files. I've even restarted the entire > server, and ran it with iso-8859-2 settings and utf-8 encoded .mo files. > However, I haven't tried the help files, since there are no hungarian help > files :( OK, help files pose a serious problem. They seem to be some plain HTML stuff without any encoding information, which means, they must be converted together with changing the CHARSET value. Regards, Tamás ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ----- squirrelmail-i18n mailing list Posting guidelines: http://squirrelmail.org/postingguidelines Information about translations: http://squirrelmail.org/wiki/LanguageTranslation Statistics for translations: http://l10n-stats.squirrelmail.org/ List address: squirrelmail-i18n@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n |
| Free embeddable forum powered by Nabble | Forum Help |
