Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
Robin Rosenberg wrote: > Not a problem in practice since I think "international" servers would not > use national characters. So even if all characters do not work, so be it, if > the common ones work. It's really only a few that I'm interested in, i.e. åäöÅÄÖ, > i.e. characters people tend to use. It's a problem because eg. there are quite a few Japanese users of CVSNT - it's not really a solution if it excludes them. > Have there been any discussions on how, i.e. an agreement in principle > on how to solve this, so that if someone implements it or part of it patches > won't be rejected right away? > > I had a kludgy idea of setting up server on different ports. 2401 for ISOLatin1, 2402 > for UTF-8, but I'd rather skip that. It's a future problem, but it blocks any linux client > from having clients with UTF-8 as the default charset. Som linux distributions nowadays > default to UTF-8. ... which is a problem because NT support for UTF8 is minimal (in fact, it's virtually nonexistant, beyond converting to/from Unicode). Since all the text output of CVS is generated by the server, it impacts almost every area of the code if there's going to be any changes. How do eg. Sourceforge handle this? I have tried to produce a UTF8 version of CVSNT and decided the effort at the moment outweighs the advantages - there's the new code coming onstream that'll be UTF8 at the core (the first chunk of that is due to go in once the current lot becomes stable) but that's a long process and will only happen in stages (long = 6 months if the funding happens). Tony