Re: [Edbrowse-dev] andTranslate

[Adam Thompson <arthompson1990@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

On Wed, Feb 26, 2014 at 09:10:01AM -0500, Karl Dahlke wrote:
> Yeah, if the user's console is iso 8859-1, I would embed the unicode if less than 256,
> or just put a question mark if higher and untranslated in the config file.
> I, like you, think this is not a big problem;
> almost everyone is utf8 by now.

I hope so as otherwise some of the js stuff's going to do odd things.
I remember this came up when we were first playing with mozjs 24 and the
decision was that it shouldn't be a problem for js strings (intended for console output) so we may as well
take the same approach here.

I like the ability to translate things in the config file.
I almost wonder if it wouldn't be nicer to have some more generic utf8
translation mechanism available (haven't really thought how to handle input),
perhaps available as a toggle.
This'd help those of us who use edbrowse on odd consoles (or ones which claim to be utf8 but won't display it) or with screenreaders
which don't do utf8. It'd be kind of nice to tell edbrowse to 
translate the utf8 in whatever I'm reading into whatever form I've
told it to use with a single command, rather than a set of substitutions.

I know I can sit down with an utf8 table and set up all the substitutions as a
function, but if we're going to do the mechanism anyway I wonder if we can move
it from format.c to somewhere else.

This way the mechanism would be:
- Do all the mandatory html translations (< > etc) as now in format.c
- put any utf8 in the output
- if console is iso8859 translate according to the existing rules and the config file
- if not and the user wants utf8 translation (broken console,
screen reader or whatever) perform just the config file driven part of the translation

If I remember rightly the non-utf8 console step is performed for all files at
the moment, and I'd like to put the utf8 but broken step as a command to be ran
on non-html files as well.

As you say though this is a potentially large change and should probably wait
till the next release (or at least till we've thought through everything).

Karl or Chris, is there any chance one (or both)
of you could send an email to our debian contact as I've got nothing back from my email.

Cheers,
Adam.
PS: I'll try emailing them again when I get time

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]