So I've finally taken the plunge and converted my system to UTF-8. Apart from getting more spam in legible characters now I can look at translations and see the right characters when I convert them with iconv. This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now. Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it? Diego
On Saturday, 28 October 2006 at 17:14, Diego Biurrun wrote:
So I've finally taken the plunge and converted my system to UTF-8. Apart from getting more spam in legible characters now I can look at translations and see the right characters when I convert them with iconv.
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it?
There's a vote going on on Polish translation team private mailing list currently and the result is 2:1 in favour so far. Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
On Sat, Oct 28, 2006 at 05:43:20PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 28 October 2006 at 17:14, Diego Biurrun wrote:
So I've finally taken the plunge and converted my system to UTF-8. Apart from getting more spam in legible characters now I can look at translations and see the right characters when I convert them with iconv.
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it?
There's a vote going on on Polish translation team private mailing list currently and the result is 2:1 in favour so far.
What are the arguments against it? Diego
On Saturday, 28 October 2006 at 18:56, Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:43:20PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 28 October 2006 at 17:14, Diego Biurrun wrote:
So I've finally taken the plunge and converted my system to UTF-8. Apart from getting more spam in legible characters now I can look at translations and see the right characters when I convert them with iconv.
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it?
There's a vote going on on Polish translation team private mailing list currently and the result is 2:1 in favour so far.
What are the arguments against it?
Local conversion burden, one translator is using ISO8859-2 locale, but another is using it, too, and doesn't mind. Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Hello, On Sat, Oct 28, 2006 at 08:08:40PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 28 October 2006 at 18:56, Diego Biurrun wrote:
What are the arguments against it?
Local conversion burden, one translator is using ISO8859-2 locale, but another is using it, too, and doesn't mind.
Where in the process is conversion needed? Shouldn't editors be able to handle it transparently? I think even subversion can convert if you use "svn di" (not 100% sure though). Greetings, Reimar Döffinger
On Sun, Oct 29, 2006 at 09:52:05AM +0100, Reimar Döffinger wrote:
Hello, On Sat, Oct 28, 2006 at 08:08:40PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 28 October 2006 at 18:56, Diego Biurrun wrote:
What are the arguments against it?
Local conversion burden, one translator is using ISO8859-2 locale, but another is using it, too, and doesn't mind.
Where in the process is conversion needed? Shouldn't editors be able to handle it transparently? I think even subversion can convert if you use "svn di" (not 100% sure though).
When editing on a non-utf system. And at least my editor (vim 6.1) isn't able to handle it transparently (although it's so little work, I can thing of it as transparent and I don't complain about it), or, more probably, I haven't found how to make it happen. And letting SVN handle it is a Bad Idea, as XML documents contain encoding in first line. I don't think SVN is smart enough to change this as well, so if you let SVN to, for example, let user have the file in their own encoding and convert it to utf-8 on commit, then either user or repository is going to have wrong encoding information, thus breaking build probably. Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 3073512 torinthiel(at)megapolis(dot)pl gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999 D714 7CEB CDDC 0906 A2CE "No classmates may be used during this examination"
Hello, On Sun, Oct 29, 2006 at 10:38:19AM +0100, Torinthiel wrote:
On Sun, Oct 29, 2006 at 09:52:05AM +0100, Reimar Döffinger wrote:
Where in the process is conversion needed? Shouldn't editors be able to handle it transparently? I think even subversion can convert if you use "svn di" (not 100% sure though).
When editing on a non-utf system. And at least my editor (vim 6.1) isn't able to handle it transparently (although it's so little work, I can thing of it as transparent and I don't complain about it), or, more
set fileencodings+=utf-8 in your vimrc.
probably, I haven't found how to make it happen. And letting SVN handle it is a Bad Idea, as XML documents contain encoding in first line. I don't think SVN is smart enough to change this as well, so if you let SVN to, for example, let user have the file in their own encoding and convert it to utf-8 on commit, then either user or repository is going to have wrong encoding information, thus breaking build probably.
No, of course not, I was only talking about "svn diff" to e.g. review changes. Greetings, Reimar Döffinger
On Sun, Oct 29, 2006 at 10:47:06AM +0100, Reimar Döffinger wrote:
set fileencodings+=utf-8 in your vimrc.
First, it doesn't work. 'set fileencodings+=utf-8' doesn't do anything, neither does with + instead of +=. Also tried autocmd BufNewFile,BufRead *.xml set fileencoding+=utf-8 This one (or without '='), at least sets fileencoding, but doesn't translate file. Anyway, even if it had worked, this would affect ALL of my files, and this is something I definitely don't want. Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 3073512 torinthiel(at)megapolis(dot)pl gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999 D714 7CEB CDDC 0906 A2CE "No classmates may be used during this examination"
Hello, On Sun, Oct 29, 2006 at 10:58:33AM +0100, Torinthiel wrote:
On Sun, Oct 29, 2006 at 10:47:06AM +0100, Reimar Döffinger wrote:
set fileencodings+=utf-8 in your vimrc.
First, it doesn't work. 'set fileencodings+=utf-8' doesn't do anything, neither does with + instead of +=. Also tried autocmd BufNewFile,BufRead *.xml set fileencoding+=utf-8 This one (or without '='), at least sets fileencoding, but doesn't translate file.
Then either vim is not compiled with everything needed or you have neither $LANG nor encoding set correctly so vim does not know what your terminal expects.
Anyway, even if it had worked, this would affect ALL of my files, and this is something I definitely don't want.
fileencoding yes, but fileencodings only sets which types vim tries to auto-detect, and UTF-8 autodetection should be really safe. try set fileencodings=utf8 and then set fileencodings+= whatever else you tend to use (just fileencodings+=utf-8 probably won't work if something with no proper autodetection comes before). Greetings, Reimar Döffinger
Then either vim is not compiled with everything needed or you have neither $LANG nor encoding set correctly so vim does not know what your terminal expects.
None of the above ;)
Anyway, even if it had worked, this would affect ALL of my files, and this is something I definitely don't want.
fileencoding yes, but fileencodings only sets which types vim tries to auto-detect, and UTF-8 autodetection should be really safe. try set fileencodings=utf8 and then set fileencodings+= whatever else you tend to use (just fileencodings+=utf-8 probably won't work if something with no proper autodetection comes before).
Ahhh, here was the problem. I've used fileencoding, not fileencoding_s_. Now works well, thanks! I still don't get how it creates iso-8859 files by default, when first position in fileencodings is utf, but I'm not going to dive into this now that it works ;) Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 3073512 torinthiel(at)megapolis(dot)pl gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999 D714 7CEB CDDC 0906 A2CE "No classmates may be used during this examination"
Hello, On Sun, Oct 29, 2006 at 11:59:02AM +0100, Torinthiel wrote:
I still don't get how it creates iso-8859 files by default, when first position in fileencodings is utf, but I'm not going to dive into this now that it works ;)
Probably defaults to the encoding of your locale. You con do something similar to what I do for mutt, set an alias for: vim "+set fenc=utf-8" to create utf8-files. Greetings, Reimar Döffinger
Hi, On Oct 28, 2006, at 5:14 , Diego Biurrun wrote:
So I've finally taken the plunge and converted my system to UTF-8. Apart from getting more spam in legible characters now I can look at translations and see the right characters when I convert them with iconv.
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators?
As far as I am concerned, I rejected all suggestions (made by some contributors) to convert .fr translated files to UTF-8. Why? - if it ain't broke, don't fix it - I'm dead sure that every French person is able to edit an ISO latin-1 file without any trouble, whereas I can't say the same thing for UTF-8 files. Anyway, if we can make the world better by converting everything to UTF-8, so be it. I think users can handle switching to a UTF-8 compliant text editor.
Any volunteers to do it?
I can take care of the .fr part if needed. Guillaume
On 28 Oct 2006 19:14, Diego Biurrun wrote:
So I've finally taken the plunge and converted my system to UTF-8. Apart from getting more spam in legible characters now I can look at translations and see the right characters when I convert them with iconv.
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it?
There are possible several problems with russian translation: not all systems support utf-8 well, there are troubles with some text editors and browsers. Of course, converting using iconv is always possible, but this will make things less usable and will take additional time for dealing with documentation, particularly for me.
Hello, On Sun, Oct 29, 2006 at 03:40:42AM +0300, Andrew Savchenko wrote:
There are possible several problems with russian translation: not all systems support utf-8 well, there are troubles with some text editors and browsers.
Same to you: can you be more specific where the problems are? Most likely other people encountered the same problems and found ways to fix them. [...] Greetings, Reimar Döffinger
Hi! On 29 Октябрь 2006 11:54 Reimar Döffinger wrote:
On Sun, Oct 29, 2006 at 03:40:42AM +0300, Andrew Savchenko wrote:
There are possible several problems with russian translation: not all systems support utf-8 well, there are troubles with some text editors and browsers.
Same to you: can you be more specific where the problems are?
Well, there are some of them. Editors wich doesn't support utf8 at all in my system: mcedit, vim. Links (my favourite browser) can't work with it also. There are more sophisticated problems: when mounting vfat cp1251 (e.g. usb flash device) on host with utf8 locale all non-english characters in filenames become completely broken and iocharset, and codepage mount options won't help. I don't know why for now, maybe something wrong in the kernel. Also some russian man pages became broken on my system, with utf8 locale; of course I can use english one's or convert national pages into utf8, but the last is some kind of headache.
Most likely other people encountered the same problems and found ways to fix them.
Yes. All this problems can be fixed, I know that. But, I need to find/wrote somehow appropriate patches, or find helper applications, or spend a lot of traffic for upgrade one program, another and so on. If I'll spend all weak without doing any other work, I'll assuredly convert my whole system to full utf8 support, including locale. But, why I must take deal with all this troublesome headache? Only for idea that utf8 is better and certainly is more proper way to handle encodings? Yes it is better, no doubt, utf8 is principially better than any other solutions for manage different encoding (but it has a disadvantage also: non-english text files becomes at least twice larger than original ones). And, once again, there is still shabby support of utf8 in some applications. But my locale is not utf8 (this doesn't mean that I have no utf8 at all) and I almost have no troubles when dealing with english, russian and even with japaneese texts. Why I must change something? If documentation encoding explicitly will be changed to utf8, I'll be forced to use iconv, even for reading it. This is solution, but it will make things much less suitable and more time-consuming, so I don't want this changes. Using non-utf8 ecoding won't hurt anyone. Outspread of utf8 is not an option: a lot of people use window$, but this doesn't mean that I must do the same. Imho utf8 is still not suitable enough for some, especially cyrillic systems.
Hello, On Sun, Oct 29, 2006 at 01:13:10PM +0300, Andrew Savchenko wrote:
On 29 ?????????????? 2006 11:54 Reimar Döffinger wrote:
On Sun, Oct 29, 2006 at 03:40:42AM +0300, Andrew Savchenko wrote:
There are possible several problems with russian translation: not all systems support utf-8 well, there are troubles with some text editors and browsers.
Same to you: can you be more specific where the problems are?
Well, there are some of them. Editors wich doesn't support utf8 at all in my system: mcedit, vim. Links (my favourite browser) can't work with it also.
vim should definitly support it. And links, if even remotely standards-compilant absolutely must support it. I think you misunderstood me, because the rest of the post talked about converting the whole system to UTF-8, but there should be no need for it. I am only talking about editing files, creating patches etc. for files in UTF-8. In theory your system charset should be completely irrelevant as long as it can display all needed characters. If it doesn't, I'd find it worth to find out why, because I do see quite some UTF-8 stuff around, like web pages and subtitles. Greetings, Reimar Döffinger
On Sun, Oct 29, 2006 at 11:27:11AM +0100, Reimar Döffinger wrote:
vim should definitly support it. And links, if even remotely
vim 6.1 definitely supports it, tested. Try editing a utf-8 file, and if it doesn't display well try ':e ++enc=utf-8', works for me. Also see same thread, I've just automated my vim. But then, tested only for Polish, not Russian. Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 3073512 torinthiel(at)megapolis(dot)pl gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999 D714 7CEB CDDC 0906 A2CE "No classmates may be used during this examination"
On 29 Oct 2006 14:04 Torinthiel wrote:
On Sun, Oct 29, 2006 at 11:27:11AM +0100, Reimar Döffinger wrote:
vim should definitly support it. And links, if even remotely
vim 6.1 definitely supports it, tested. Try editing a utf-8 file, and if it doesn't display well try ':e ++enc=utf-8', works for me. Also see same thread, I've just automated my vim. But then, tested only for Polish, not Russian.
Thanks very much, this works for Russian too.
Hello, On 29 Oct 2006 13:27, Reimar Döffinger wrote:
On Sun, Oct 29, 2006 at 01:13:10PM +0300, Andrew Savchenko wrote:
On 29 ?????????????? 2006 11:54 Reimar Döffinger wrote: <skip>
Same to you: can you be more specific where the problems are?
Well, there are some of them. Editors wich doesn't support utf8 at all in my system: mcedit, vim. Links (my favourite browser) can't work with it also.
vim should definitly support it. And links, if even remotely standards-compilant absolutely must support it.
Yes, 6.4 supports it well, thanks for Torinthiel and you, I gave wrong command earlier; seems I should RTFM vim again 8-\. So my objections against converting to utf8 are obsolete.
I think you misunderstood me, because the rest of the post talked about converting the whole system to UTF-8, but there should be no need for it.
Sorry for misunderstanding you, I should read posts carefully.
2006/10/29, Andrew Savchenko <Bircoph@list.ru>:
Hello,
On 29 Oct 2006 13:27, Reimar Döffinger wrote:
On Sun, Oct 29, 2006 at 01:13:10PM +0300, Andrew Savchenko wrote:
On 29 ?????????????? 2006 11:54 Reimar Döffinger wrote: <skip>
Same to you: can you be more specific where the problems are?
Well, there are some of them. Editors wich doesn't support utf8 at all in my system: mcedit, vim. Links (my favourite browser) can't work with it also.
vim should definitly support it. And links, if even remotely standards-compilant absolutely must support it.
Yes, 6.4 supports it well, thanks for Torinthiel and you, I gave wrong command earlier; seems I should RTFM vim again 8-\.
So my objections against converting to utf8 are obsolete.
I'm ready to convert DOCS/ru from koi8-r to UTF-8. Ok to proceed? -- Regards, Vladimir Voroshilov mailto:voroshil@gmail.com JID: voroshil@jabber.ru ICQ: 95587719
On Sun, Oct 29, 2006 at 01:13:10PM +0300, Andrew Savchenko wrote:
Hi!
On 29 Октябрь 2006 11:54 Reimar Döffinger wrote:
On Sun, Oct 29, 2006 at 03:40:42AM +0300, Andrew Savchenko wrote:
There are possible several problems with russian translation: not all systems support utf-8 well, there are troubles with some text editors and browsers.
Same to you: can you be more specific where the problems are?
Well, there are some of them. Editors wich doesn't support utf8 at all in my system: mcedit, vim. Links (my favourite browser) can't work with it also.
Modern development versions of ELinks (nice fork of Links 0.9x) have good UTF-8 support except for nonspacing and CJK wide characters, which have "issues". Dunno if there's any work on fixing the fork that's still called plain "Links" but it needs to be done..
There are more sophisticated problems: when mounting vfat cp1251 (e.g. usb flash device) on host with utf8 locale all non-english characters in filenames become completely broken and iocharset, and codepage mount options won't help. I don't know why for now, maybe something wrong in the kernel.
Are you using the "utf8" mount option? This, along with the codepage and iocharset options, may be needed. Unfortunately the docs are really bad and I can't quite figure out for sure which ones you need but those are the ones to try. Aside #1: using UTF-8 encoding for the docs does not require converting your system locale if you have an editor that can edit UTF-8. Aside #2: if these things are broken maybe you can help with getting them fixed so that its easier for people to switch to UTF-8. OTOH I understand that this is a pain and you might not want to do it. Rich
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it?
One question: What is a good way to find out the encoding of a file? help/help_mp-mk.h is marked as UTF-8, but this is wrong. file does not say that it is UTF-8-encoded as it does for some other help files and the file looks wrong in vim on my UTF-8 system (although I see seemingly correct cyrillic with cat and less..). Also, iconv complains about "iconv: illegal input sequence at position 3839" when converting the file to UTF-8... Diego
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
This makes me think that the moment to convert everything to UTF-8 may have come. Others have been lobbying for it before, I'm willing to go along now.
Is there anything that speaks against the conversion? Will it cause problems for translators? Any volunteers to do it?
One question: What is a good way to find out the encoding of a file?
On some occasions, I was wondering about the same..
help/help_mp-mk.h is marked as UTF-8, but this is wrong. file does not say that it is UTF-8-encoded as it does for some other help files and the file looks wrong in vim on my UTF-8 system (although I see seemingly correct cyrillic with cat and less..). Also, iconv complains about "iconv: illegal input sequence at position 3839" when converting the file to UTF-8...
Hm, strange behaviour for me too. For example, kwrite shows the characters correctly and indicates utf-8 as encoding (all cryllic ones I tried garbled the text).About the "illigal input sequence" (that occured here too), this seems due to some very weird character for space or \three-dots. I fixed it (->patch) and conversion (iconv -t utf8 ..) works fine. Also, a diff from before and after iconv shows no difference. Still wondering about wrong display in vim but I think the encoding is indeed utf-8. Btw, that was chosen by reimar in r18115 where the .charset files were created. Sebastian PS: Since that probably won't hurt, I'll apply attached patch soon. PPS: I'm not sure if this file is of much use any more, it's initial translation dates back to end of 2003 (r11524); after that, only general changes/fixes were applied. I might try to contact the initial author.
Hm, strange behaviour for me too. For example, kwrite shows the characters correctly and indicates utf-8 as encoding (all cryllic ones I tried garbled the text).About the "illigal input sequence" (that occured here too), this seems due to some very weird character for space or \three-dots. I fixed it (->patch) and conversion (iconv -t utf8 ..) works fine.
It seems vim was checking the whole file and didn't understand this character. Since I applied my change, vim displays everything correctly. :)Diego, can you verify? Sebastian
On Mon, Oct 30, 2006 at 03:42:21PM +0100, mail@kraymer.de wrote:
Hm, strange behaviour for me too. For example, kwrite shows the characters correctly and indicates utf-8 as encoding (all cryllic ones I tried garbled the text).About the "illigal input sequence" (that occured here too), this seems due to some very weird character for space or \three-dots. I fixed it (->patch) and conversion (iconv -t utf8 ..) works fine.
It seems vim was checking the whole file and didn't understand this character. Since I applied my change, vim displays everything correctly. :)Diego, can you verify?
Yes, it works, apply! Diego
On Mon, Oct 30, 2006 at 03:42:21PM +0100, mail@kraymer.de wrote:
Hm, strange behaviour for me too. For example, kwrite shows the characters correctly and indicates utf-8 as encoding (all cryllic ones I tried garbled the text).About the "illigal input sequence" (that occured here too), this seems due to some very weird character for space or \three-dots. I fixed it (->patch) and conversion (iconv -t utf8 ..) works fine.
It seems vim was checking the whole file and didn't understand this character. Since I applied my change, vim displays everything correctly. :)Diego, can you verify?
Yes, it works, apply!
Applied. :)
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next. I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic. The graphical browsers I tested (Firefox, Opera) have no problems with it. Of the text mode browsers lynx, links and elinks were broken, but w3m was fine (but Rich mentioned that development versions of elinks can do UTF-8). Can you people test some other browsers on your setups please? Diego
On Fri, Nov 10, 2006 at 04:30:09PM +0100, mail@kraymer.de wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch.
Which patch? :)
*sigh* Diego
Hello, On Fri, Nov 10, 2006 at 04:45:59PM +0100, Diego Biurrun wrote:
+ <xsl:param name="chunker.output.encoding" select="'utf-8'"/> + <xsl:output encoding="utf-8"/> +
Want to already ask last time: Is utf-8 the right way? Because in configure we use "UTF-8" since not all iconv variants accept "utf-8". Greetings, Reimar Döffinger
On Fri, Nov 10, 2006 at 04:50:44PM +0100, Reimar Döffinger wrote:
On Fri, Nov 10, 2006 at 04:45:59PM +0100, Diego Biurrun wrote:
+ <xsl:param name="chunker.output.encoding" select="'utf-8'"/> + <xsl:output encoding="utf-8"/> +
Want to already ask last time: Is utf-8 the right way? Because in configure we use "UTF-8" since not all iconv variants accept "utf-8".
iconv always accepted UTF-8 for me, did I only test the GNU variant or something? In any case, this is about xsltproc, not iconv, so the point is moot. Diego
Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic.
The graphical browsers I tested (Firefox, Opera) have no problems with it. Of the text mode browsers lynx, links and elinks were broken, but w3m was fine (but Rich mentioned that development versions of elinks can do UTF-8). Can you people test some other browsers on your setups please?
These are works fine with utf-8: Links 2.1pre20 Lynx 2.8.5rel.5 System: Gentoo 2006.1 with latest updates.
Diego _______________________________________________ MPlayer-DOCS mailing list MPlayer-DOCS@mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/mplayer-docs
-- Regards, Vladimir Voroshilov mailto:voroshil@gmail.com Omsk State University JID: voroshil@jabber.ru ICQ: 95587719
On Fri, Nov 10, 2006 at 04:22:55PM +0100, Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic.
So no objections? Diego
2006/11/12, Diego Biurrun <diego@biurrun.de>:
On Fri, Nov 10, 2006 at 04:22:55PM +0100, Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic.
So no objections?
Diego I have no. Russian docs displays correctly, but convertion will need additional modfication in ru/* files (removing *.xsl and modifiction of Makefile) _______________________________________________ MPlayer-DOCS mailing list MPlayer-DOCS@mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/mplayer-docs
-- Regards, Vladimir Voroshilov mailto:voroshil@gmail.com JID: voroshil@jabber.ru ICQ: 95587719
On 12 Nov 2006 16:53, Diego Biurrun wrote:
On Fri, Nov 10, 2006 at 04:22:55PM +0100, Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic.
So no objections?
It seems that no. At least links-2.1-0.pre20 works fine with utf8.
On Sun, Nov 12, 2006 at 02:53:33PM +0100, Diego Biurrun wrote:
On Fri, Nov 10, 2006 at 04:22:55PM +0100, Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic.
So no objections?
I've heard none, so I'm going to make the change tomorrow. Diego
On Tue, Nov 14, 2006 at 05:01:40PM +0100, Diego Biurrun wrote:
On Sun, Nov 12, 2006 at 02:53:33PM +0100, Diego Biurrun wrote:
On Fri, Nov 10, 2006 at 04:22:55PM +0100, Diego Biurrun wrote:
On Sat, Oct 28, 2006 at 05:14:29PM +0200, Diego Biurrun wrote:
[...]
OK, we have taken the first step, now comes the next.
I propose switching the output of the HTML conversion of the XML documentation to be UTF-8, see my attached patch. I believe that modern browsers don't have trouble with UTF-8 so this change should not be problematic.
So no objections?
I've heard none, so I'm going to make the change tomorrow.
Done. Diego
Moin, I know i'm late, but still... If you are looking for a lean editor to quickly edit utf-8 check out leafpad. It's a GTK2 editor (no dependency on gnome!) and can eat all character sets i've ever thorwn at it. Not to mention that it can use all GTK2 input methods, so it's possible to enter even raw unicode strings if needed (given you have scim or something similar installed). Attila Kinali -- Lotus Notes ist eine verteilte Datenbankapplikation, als Sample ist eine miese Groupware dabei ;) -- Lukas Beeler
participants (11)
-
Andrew Savchenko -
Attila Kinali -
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Guillaume Poirier -
mail＠kraymer.de -
Reimar Döffinger -
Rich Felker -
Torinthiel -
Vladimir Voroshilov -
voroshil＠gmail.com