← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
12:31 | lloyd_ | mm whre's realy bot gone |
13:08 | kados | paul: are you around? |
13:13 | hdl | hi kados |
13:13 | kados | hey hdl |
13:16 | owen | Hi guys |
13:16 | kados | hey owen |
13:29 | paul | hi back kados & hi owen. |
13:30 | kados : we have 2 solutions : either a syspref to choose what languages to display (simpler), or let the user choose in a tools/ which translations to generate & let him DL .po files from translate.koha.org (much more complex) | |
13:32 | owen | The best interface for language selection would probably be a set of checkboxes, which you couldn't do with systempreferences the way its set up now |
13:33 | ...Unless there was an interface for installing/uninstalling translations | |
13:41 | kados | paul: I think all of the translations should be pre-generated for every release |
13:42 | paul: and we just need a syspref to say which ones to display | |
13:42 | or as owen says, a set of checkboxes | |
14:42 | hdl | kados : question about z3950 search and ImportBreeding. |
14:43 | Both are using FixEncoding. I think that from a performance point of view this is not the best solution. | |
14:44 | Is there a reason to do FixEncoding in ImportBreeding rather than having it in z3950 search ? | |
14:59 | gmcharlt | hdl: for some Z39.50 servers, that would be an improvement, yes |
14:59 | hdl: but in the general case, you don't always know the encoding of a MARC record returned by a Z39.50 server without checking it first | |
14:59 | hdl | what would be an improvement ? |
15:00 | gmcharlt | hdl: using YAZ to try to convert a MARC record the UTF8 |
15:37 | kados | gmcharlt: bulkauthimport.pl dies with encoding issues with the sample data I tried ... |
15:37 | gmcharlt: would FixEncoding be the solution to that? | |
15:38 | gmcharlt | possibly -- I'll work on it |
15:38 | kados | k |
15:57 | hdl | kados : is your data with diacritics ? |
16:04 | kados | hdl: yes |
16:05 | hdl | I found that there were some serious issues with utf8 and unicode management. |
16:05 | For instance : | |
16:05 | é has 3 representations. | |
16:06 | And we have to normalize data so that we produce the é that will be recognized in Unicode XML. | |
16:07 | Even the char_decode as it was could not help solving this for me. | |
16:07 | gmcharlt | hdl: what is the name of the character you're talking about: not showing up in my IRC view? |
16:08 | hdl | Because it would produce é as \xc3\xa9 (E ACUTE) |
16:08 | but \xc3\xa9 is known as hangul character and not E ACUTE. | |
16:09 | I just sent a new FixEncoding | |
16:09 | That uses encoding information (little change in z3950servers table) | |
16:10 | And uses Text::Iconv for the most encoding problems. | |
16:10 | ISO5426 is assigned by a new char_decode5426 | |
16:48 | owen | Hey pate |
16:48 | pate | hiya owen |
16:48 | hdl | hi pate |
16:48 | owen | I saw in the log you popped in the other day. How's it going? |
16:48 | pate | pretty well |
16:48 | hdl | Happy New Year |
16:49 | pate | thanks hdl, and the same to you |
16:49 | I figured it was time I checked in and saw how koha is doing these days | |
16:49 | it looks like you guys are really getting stuff done with it | |
16:50 | owen | You betcha |
16:50 | atz | yeah, it's been on high gear lately |
17:10 | kados | pate: we have our first Armenian translation :-) |
17:12 | pate | cool! |
← Previous day | Today | Next day → | Search | Index