{"thread":{"id":"6184","subject":"i18n, alternative solution","startedAt":"2007-01-01T14:47:47Z","lastAt":"2007-01-07T16:55:33Z","messageCount":3,"participants":["Robin Rosenberg","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30620","messageId":"200701011547.48697.robin.rosenberg.lists@dewire.com","threadId":"6184","inReplyTo":null,"subject":"i18n, alternative solution","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-01-01T14:47:47Z","receivedAt":"2007-01-01T14:47:47Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Hi and Happy New Year\n\nThings are happening wrt to support for working with multiple locales, which \nis nice to see. I've not had time to follow the development so these comments \n(and code) may be considered somewhat late in the process.\n\nWhat disturbes me is the complexity that the approach of storing multiple \nencodings in the same repository results in. I was hacking another solution \nearlier this autumn, that takes another approach, i.e. UTF-8 is the internal \nencoding. period. If you want to working with anything else, you convert on \ninput and output. The code is very simply since it has few cases to consider \nand I don' t need to store encoding anywhere. What is missing is a flags to \ndisable i18n for a flag (or enable it). \n\nThe uglyness is the filename parts since I catch all filename operations and \nnot only the ones I need. The target wasn't final code, but to prove that it \ncould be done.\n\nThe focus is on file names, but commit messages were included since it was so \nsimple. You can get the code at http://rosenberg.homelinux.net/repos/GIT.git \non the branch i18n. I modded the testcases to verify that GIT works after the \npatches, but one would probably prefer to write new test cases for UTF-8. \n\n5d73e28397f7ec0f85fcb8e31e91326afbcfea19 is the last commit that executes all \ntest cases successfully. \n\nI could send the code as patches if you like, not on top of the lastest \nversion though, but 1.4.2-something,\n\n-- robin\n"},{"id":"30621","messageId":"7vy7om7cs0.fsf@assigned-by-dhcp.cox.net","threadId":"6184","inReplyTo":"200701011547.48697.robin.rosenberg.lists@dewire.com","subject":"Re: i18n, alternative solution","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-01T19:44:15Z","receivedAt":"2007-01-01T19:44:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:\n\n> What disturbes me is the complexity that the approach of storing multiple \n> encodings in the same repository results in.\n\nWe are not encouraging mixed encodings, mind you.\n\nEven though we check and warn comits that do not have a valid\nUTF-8 string, the users can make mistakes and people need be\nable to look at them later.  That is what we are solving.  \n\nAt the same time we do NOT force inconvenience on projects that\nwant to use legacy encoding for whatever reason.  The world is\nnot UTF-8 only, and encoding to UTF-8 is non-reversible a times\n(positive return value from iconv(3)).  Always re-coding to\nUTF-8 will NOT be accepted to git for now.  We can revisit this\nperhaps in 5 years.\n"},{"id":"31059","messageId":"200701071755.34496.robin.rosenberg.lists@dewire.com","threadId":"6184","inReplyTo":"7vy7om7cs0.fsf@assigned-by-dhcp.cox.net","subject":"Re: i18n, alternative solution","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-01-07T16:55:33Z","receivedAt":"2007-01-07T16:55:33Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 01 januari 2007 20:44 skrev Junio C Hamano:\n> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:\n> > What disturbes me is the complexity that the approach of storing multiple\n> > encodings in the same repository results in.\n>\n> We are not encouraging mixed encodings, mind you.\n>\n> Even though we check and warn comits that do not have a valid\n> UTF-8 string, the users can make mistakes and people need be\n> able to look at them later.  That is what we are solving.\n\nMy is to not convert at all if the uset  has locale=UTF-8. Mostly it's an\noptimization, but it also has the effect of getting the raw message.\n\n> At the same time we do NOT force inconvenience on projects that\n> want to use legacy encoding for whatever reason.  The world is\n> not UTF-8 only, and encoding to UTF-8 is non-reversible a times \n> (positive return value from iconv(3)).  Always re-coding to\n> UTF-8 will NOT be accepted to git for now.  We can revisit this\n> perhaps in 5 years.\n\nAccording to the unicode FAQ, unicode is a superset of all local \nencodings, so why would the conversion be non-reversible for local \nvs utf-8?\n\nIn five years there will be so much legacy, that fixing it in a simple way \nwill be unfeasble (just like CVS,  FTP, etc).\n\n-- robin\n"}]}