JavaScript C:\SBBS\xtrn\syncWXremix\wxlanguage.js line 68: TypeError: opts.language is undefined
Re: WX
By: Android8675 to All on Wed Mar 02 2016 11:58:35
JavaScript C:\SBBS\xtrn\syncWXremix\wxlanguage.js line 68: TypeError: opts.language is undefined
Looks like there are a few problems with that script. I would suggest trying the following:
Change line 9 to:
if (typeof opts.language === 'undefined') {
opts.language = 'EN';
If that helps, perhaps Ken can incorporate it.
Re: WX
By: Android8675 to All on Wed Mar 02 2016 11:58:35
JavaScript C:\SBBS\xtrn\syncWXremix\wxlanguage.js line 68: TypeError: opts.language is undefined
Looks like there are a few problems with that script. I would suggest trying the following:
Change line 9 to:
if (typeof opts.language === 'undefined') {
opts.language = 'EN';
If that helps, perhaps Ken can incorporate it.
The only thing the GitHub code has over Ver 1.04 is the beginnings of language support (aka internationalization) for Spanish and Italian (other translations are welcome if someone wants to submit some). However, for languages other than English I've made the characters UTF-8/Unicode as opposed to CP437, since the accents on non-English characters will not show up correctly in CP437. (Ex. Monday in Italian is Lunedì, ending in an "i" with the grave accent which looks awkward in CP437).
The only thing the GitHub code has over Ver 1.04 is the beginnings of
language support (aka internationalization) for Spanish and Italian
(other translations are welcome if someone wants to submit some).
However, for languages other than English I've made the characters
UTF-8/Unicode as opposed to CP437, since the accents on non-English
characters will not show up correctly in CP437. (Ex. Monday in Italian
is Lunedì, ending in an "i" with the grave accent which looks awkward
in CP437).
Are you using a terminal program that supports UTF-8?
Most BBS terminal programs that I'm aware of (e.g. SyncTERM) do not support UTF-8, so that's not going to work well with the majority of clients. Or is this for a web UI (where UTF-8 is widely supported)?
Re: Re: WX
By: Digital Man to KenDB3 on Sat Mar 05 2016 07:37 pm
The only thing the GitHub code has over Ver 1.04 is the beginnings of
language support (aka internationalization) for Spanish and Italian
(other translations are welcome if someone wants to submit some).
However, for languages other than English I've made the characters
UTF-8/Unicode as opposed to CP437, since the accents on non-English
characters will not show up correctly in CP437. (Ex. Monday in Italian
is Lunedì, ending in an "i" with the grave accent which looks awkward
in CP437).
Are you using a terminal program that supports UTF-8?
Most BBS terminal programs that I'm aware of (e.g. SyncTERM) do not support UTF-8, so that's not going to work well with the majority of clients. Or is this for a web UI (where UTF-8 is widely supported)?
So, it is for the Terminal, and not a Web UI.
Honestly, this was my attempt to support a request I got (on GitHub) for i18n support. First, I had to look up "i18n" to find out it meant internationalization. But, then I saw that Weather Underground's API actually supports this, but it's a bit of a catch-22.
The data that comes back has UTF-8 characters, like the days of the week example I threw into my last post. I am pretty sure the W.U. API wasn't expecting much stuff other than Web UI. I really have no idea what character set would support the accented characters besides UTF-8, but I tested with few different fonts in SyncTERM, including ISO-8859-15 West European and ISO-8859-2 Central European, but no luck.
I'm able to see everything in UTF-8 just fine using PuTTY release 0.66, using UTF-8 as the Remote Character Set on the Translations tab, and with a font of Courier (14-pt, Clear Type) on the Appearance tab.
JavaScript C:\SBBS\xtrn\syncWXremix\wxlanguage.js line 68:
TypeError: opts.language is undefined
Looks like there are a few problems with that script. I would suggest trying the following:
Change line 9 to:
if (typeof opts.language === 'undefined') {
opts.language = 'EN';
Right, but how does the rest of the BBS look with PuTTY set that way? Probably not very good. Right now, Synchronet doesn't support any way of detecting or tracking the user's character set or encoding and pretty much assumes CP437. You can send UTF-8 from your script, but most clients aren't going to display it correctly and there's really no way for you to know which clients will or will not display it correctly.
digital man
I think my problem is that data is coming back from Weather Underground in UTF-8, which is not a problem when it is in (US) English, but starts to present a problem with the couple of Latin based languages I tried to implement. Is there any way to clean/convert the text before displaying it?
Someone asked for this feature, and I thought it would be an easier ask than some of the other requests I got, but it proved more challenging thanks to the UTF-8 characters.
Any advice is welcome :-)
~KenDB3
Right, but how does the rest of the BBS look with PuTTY set that way? Probably not very good. Right now, Synchronet doesn't support any way of detecting or tracking the user's character set or encoding and pretty much assumes CP437. You can send UTF-8 from your script, but most clients aren't going to display it correctly and there's really no way for you to know which clients will or will not display it correctly.
digital man
So, I haven't forgotten about this, I've just been rather tied up. I see what your aiming at, and I think I'm at a bit of a disadvantage not knowing some history. It sounds like you are trying to politely tell me that UTF-8/Unicode is really not used in the BBS community, even outside the US.
But, how do other countries utilize special characters?
Or, would it be a
case where those characters are ignored and replaced with the Non-Accented characters that are more CP437 friendly?
I think my problem is that data is coming back from Weather Underground in UTF-8, which is not a problem when it is in (US) English, but starts to present a problem with the couple of Latin based languages I tried to implement. Is there any way to clean/convert the text before displaying it?
Someone asked for this feature, and I thought it would be an easier ask than some of the other requests I got, but it proved more challenging thanks to the UTF-8 characters.
Any advice is welcome :-)
I think my problem is that data is coming back from Weather Underground in UTF-8, which is not a problem when it is in (US) English, but starts to present a problem with the couple of Latin based languages I tried to implement. Is there any way to clean/convert the text before displaying it?
Yes, UTF-8 could be translated, but the results may not be very good/useful, depending on stuff (e.g. the source and target locale).
Someone asked for this feature, and I thought it would be an easier ask than some of the other requests I got, but it proved more challenging thanks to the UTF-8 characters.
Any advice is welcome :-)
Stick to US-English? :-) Seriously though, I don't really have any advice on this topic as I haven't been big on translating software to other locales or worrying about non-CP437-capable terminals. Maybe Deuce has some advice.
I think my problem is that data is coming back from Weather
Underground in UTF-8, which is not a problem when it is in (US)
English, but starts to present a problem with the couple of Latin
based languages I tried to implement. Is there any way to
clean/convert the text before displaying it?
Yes, UTF-8 could be translated, but the results may not be very
good/useful, depending on stuff (e.g. the source and target locale).
Someone asked for this feature, and I thought it would be an easier
ask than some of the other requests I got, but it proved more
challenging thanks to the UTF-8 characters.
Any advice is welcome :-)
Stick to US-English? :-) Seriously though, I don't really have any
advice on this topic as I haven't been big on translating software to
other locales or worrying about non-CP437-capable terminals. Maybe
Deuce has some advice.
In the latest CVS, there's a utf8_cp437.js file you can load()... after you do, you can call utf8_cp437(utf8_string) and it returns a cp437 version of the same string. It handles most common codepoints, but unknown ones are replaced with a question mark. If you find ones that need to be added, please let us know.
Sysop: | Clippy |
---|---|
Location: | Houston, TX |
Users: | 4 |
Nodes: | 4 (0 / 4) |
Uptime: | 74:17:39 |
Calls: | 1 |
Files: | 11 |
Messages: | 38,324 |