 Good morning. Nice to see you all here at this early hour. Especially nice to see all your tiny eyes and seeing that I'm not the only one with a terrible hangover. Before we start, I have a small announcement to make. The key signing party has been moved to tonight at 9 p.m. In the smoochie in the headglare. That's for the announcement. Just a few questions. Who of you have ever read some kind of documentation? Who of you thought that the documentation sucks? Who of you have ever written some kind of documentation? Looks interesting. So the next topic might be interesting for us all. If the second part of your name, Nukubi-san, tries to tell us something about documentation in Deviant. Stay with us. I am a drop of an open source search engine, so I usually consider to develop Deviant documentation systems for a long time. Usually, no user didn't know about the existence of such as such stuff. So some online documentation systems have their own search engine or something. So I consider that internalization seems to be more useful for Deviant. I have some ideas, but it's only from the perspective of developers. I want to hear you guys how we need to develop such documentation to be happy. So please tell me anytime if you think about this documentation. So at first, this is my conclusion. I think we need more well-documented policy in Deviant, I think. There is some useful tool, but it would not be not so automatically. So to update index or searching, it would need to decide such documentation policy. There is a background in this issue. There are some documentation systems in Deviant. The first one is to help. The second one is to be double-double-double. There is a support for text search in the documentation. And there are usually focused for such as shoot us, share us, doc directory, or map pages, or group info. But there are some other performance in Deviant. So some documentation were written in another language instead of English. However, such systems consider about only English. So I think I need a framework to handle such differences. So language is a hard problem because some languages are usually only by encodings. But other things are not. Usually, in Japanese, there are at least four kinds of encodings. You defect, and are you so too much to do JP, and be used in JP, and shift this. So in Japan, such encodings are not, such encodings is almost popular. The kind of encodings is only not so major. And then there is a good system, software, text cat. It can detect encoding automatically. But encoding at a language is not only same things. So usually, you defect can write many languages in a documentation file. So encoding detection is not equal as language detection. Alphabet is also some kind of issue, but it's not serious. There are many kinds of formats in there. Usually people use plain text, or man-pages. But some documentation were written in much pro format, like doc-book. But it will be easy to detect automatically, because there is a file command. However, to make index such a different index file format is not so easy to achieve, because some such engines implementation only supports some kinds of formats. So we need more such differences in our format. And there are many such changes in there. Already I talked about Monday's BOF about these things. So usually we have D-d-d-d-d supports, so it's plus-plus. Implementation of such engine. But it supports only single-byte encodings. So usually it is useful in the English or Sal. And single-byte languages. So I need to... Why such differences in our format? So I talked about what I need for. So that is a good way to define doc files. It is like a confile. Usually a confile is not a configuration file. Deep package system can handle it as a configuration file. So when upgrading time, it will be handled as a configuration. So if it could be merged automatically, it's done. And it couldn't be the Deep package system asked to user about some questions. So doc files also I consider such similar format. And I think I need wrapper for such engines to merge different characteristics of many engines. So then I consider about use cases. For maintainer, to make the issue to easier, I need some data helper scripts. Like doc index. It is only an index. I talked about some auto-detection framework. Some files could be easy to make some properties for property automatically. And for user perspective, I consider a data doc index package. It should be like a menu package. When user installs the package, all documentation files handle automatically. So index automatically generated and it will be ready to search. So I need to write policy. If I prepare this both, I will list many policies like menu or power or something. So it will be like such format. First of all, I can copy write and tfc and min subjects. But first I, this is my consideration about doc file format. It need to contains file path and format and languages and encodings. It will be enough to record this for things I think. So how about, is there any objection with some solution for me? What this is? First is through requirement and things. A format would be because some search engines only support a few kind of format. So to make index fan, to make index, this thing would need to detect only supported format for search engines. And also it would be same as languages or encodings. If I can define such things, so I have a plan to write this DH document doc index as script. I can say it will be tried out automatically to doc file. So text chat could be determining encodings on languages. And file command would be determining file formats. Yes? What I risk in the file you showed just now is something like section information. So you can put the file in some kind of menu structure for accessing it. So your question is, so, can I say anything? But if you have a question please. Okay. The file you showed just now, the OVG file. What I thought was missing there is some kind of information that can put a document in some kind of menu structure. Menu structure? Yes, like section information. I am not consider about it, but it is, it will be different, I think. Because usually my pages usually separate it as some sections. So it is already well, very sexualized. But many documentation files are not. So yes, I consider about this, in this slide. I think planning is a good, good information to split or sexualize. But other thing would be hard. So I think usually searching this works very fast. So it could be not so important to sexualize such as a documentation file. So for users, sexualized information would be hard to choice. So not so it shouldn't be required, I think. That would be good. So I think file format is also a good information to sexualize. Some documentations were written in some other format like HTML or SGM or such, structured information. So in that time, some of the changes could handle such structured information. So it is also useful for searching. I have no idea to sexualize other things. One, one to be good. One page section is also good things, I think. One is command, is a command one. Two is a system code, something like that. Document covers very wide range information. So it could be hard to determine such a good sexualized keywords, I think. But I, okay, I'll consider about it. So to implement the helper script, I checked a poll module named Temian, the helper, concon.dh, and the rate. It's improved by some useful functions and it could be past command or actions. If I can, I could write best implementation this time, but it could be. But I'll try it. And then update timing index is also useful. So e-max list packages are not in comparison. So it seems very similar for this framework. Or menu system is also same, I think. So it'll be a good reference for me. And then there are some such engines in Debian, but I'm not familiar with all of them. So I can prefer some engines in some use case. So switch plus plus is usually good for language. Because it was always supported by the double, double, double or the help. And namazu is good for Japanese. Because it supports good Japanese and I am a member of it. The mono usachi is also good for Chinese or Korean, because it supports such engines. Or Mito Shukai was already a product, Hi-Fi Strayer, a new brand new search engine. It supports Ngram-based search engines, so it could be useful for any kind of languages. So it could be useful for generic. And how I to do? First, I need to develop DH index. And then I need to write such Debian Poshi draft. And such engines framework is also need to implement. And what I need? The slide was a little bit over, so I want to discuss some things in this POF. You guys have any idea please? Do you think about other issue in documentation? Some viewers can auto-detect it like LB, but some like less do not. What's LB? It's like less, but it can convert between EUC and UTFH and so on. It's very easy. My English excuse is not for good for this case. The question is how to convert a Zincorin? Typically if you want to display a document, nowadays most people use X, but sometimes you want to display it in a terminal. And then you have to construct some type of terminal. Man does this in terminal. I think so. Web interface would be helpful because it could be input to client of a document encoding in its header. So, usually a web client is rich for many language handleings. So I consider to make a web interface is the most preferred thing. Terminal such client is also need, but it would be hard because the software couldn't know the terminal has what capability to display some encoding languages. So I have some research as consider to extend such not long-distance capability for terminal. So if it could be implemented, it helps, it helps us. Searching for an engine to document in different languages at the same time. So I'm not satisfied with the normal way to translation. You always have to have an English master and then you translate in the other languages. I want to have more equal rights for every language. So I'm searching for a machine who is able to index in every paragraph and has some system to inform other translators that this paragraph has changed and that there can be something like a congruence between different languages who is faster in documentation. And this we need in Schole-Linux because we are spreading all over the world and the documentation is very, very behind. So if there is another community in another language who is faster in documentation than the English one, because at the moment there is only one installation in United Kingdom, no installation in United States, about 250 installation in Norway, 50 installation in Germany and it's spreading in France now and there is no English documentation. So we have to find a system to start the documentation in every language and to put it together at least. This is a challenge. I think such a Latin language support is not so hard because I talked about insert of search engines. So usually search engines were implemented by implanted index method. It is a table to record words and file or documentation ID. So such a Latin language is usually word would be supported by space or something. So it could be easy to find words. So such a multiple language support is not hard for ordinary search engines. Actually it's not so big problem. So the problem is in Asian languages usually because it couldn't separate it in space or something. So underground base search engine is also good for such purpose because it didn't need to separate such words because it divided all documentation as two letter words for four things. So such a search engine like hyperslayer is also good for such purpose. Hyperslayer supports underground base search engine. So it is also not so depends on such language is for the handling. So then the rest issue will be encoding problem. But usually it is not hard to write English and one other languages to be stored in the same file usually because English is only written in ASCII chapters. So usually English and some other languages spare is usually useful. So two or three more main languages support would be become harder. So my talking would be one such... It's not about searching. It's about how to begin, how to do the version control. If there is somebody starting in France and somebody starting in Germany, how can we coordinate this? How can we see it? And if there is somebody in Japan starting also, oh it would be really difficult. But we need a machine who is able to show you this paragraph has changed in Japanese. The Japanese has found some things to be documented. Now the French and German guys should also change the documentation. This is what I am thinking about how we can coordinate this without an English master. There is no English master. It's not a problem of search engine. Perhaps in the long run it's a problem of search engine if you have a big document. How to construct it, how to begin without a master. This is my question. How do you suppose the French translator is going to translate a paragraph that has been added by a Japanese writer if he doesn't speak Japanese? That's the reason why we have English because almost all translators speak English. You need a common language that is spoken by the translators to be able to translate. Why do you think only in English? There are such a lot of people who are understanding Norwegian and German, nothing more. I will use this power. It's not used now. It's just used only in English and then to the arts. But you can arrange that within the community. You can define any language as your master. Only if you want to spread it around the world somebody has to take the responsibility to translate it into English. So the responsibility is always the general right. But I think you have to think about it like maybe you have a tree of languages and you have English at the top. Then you have maybe like German and Norwegians on one side in the tree. And you have Japanese, Chinese, Portuguese, Spanish on the other sides in the tree. And what you could do is you could say most development, most writing is done in German and Norwegian. So we coordinate very heavily there. Then we make sure that Norwegian and German are translated to English. And that is then the master for the rest. But that is the whole system. And I'm searching for a new system. I'm searching for another system than this old. This old system has historical reasons. Well, it's because of the imperialism of the development of the world. It's going out from the English rule. That's not true because I think there was more imperialism from France and Spain and so on. They have far more colonies. This is another topic. But I'm really looking for an equal rights system for every language to be exchanged within different languages without a master. And this is, well, it's just a challenge. It's a challenge from today because I see this need. There may be that we have to use the old system 10 years more, perhaps. But I'm searching for another system. This is the challenge. That's what I'm looking here for. But it won't work unless some people speak a common language. And the most common language is English. It's a fact of life. But you say it won't work. I'm looking for something that will work. That's the challenge. You say it won't work. No, I will try to find. And I give you the idea of how I think to start. I have a fast drawing French community. And we thought about how we could do the documentation. The idea is now that we find 10 responsible persons in German and in France who are able to understand the language, the other language. And they subscribe a wiki page. So we use two wikis, a French wiki and a German wiki. And the other language always has subscribed the important pages from the other language. Then we start comparing who is faster in documentation or installation problems and something. If there's something changing in this page, he will get an email with a diff. And then he can look up and it's missing in our page or not. That's how I start to try it. Because the traditional way for a booty is called a Linux. Then nobody wants to write a documentation, you know. Then, okay, we had to have documentation. There was a person who said, oh, my English is so bad, I will not do the documentation in English, I'll write it in Norwegian. Then we had to find someone who translated. It was difficult to find someone. Then there was somebody paid for to do it. Okay, he has done. And he has checked the English for grammar and typos and such thing. Then we had, after one and a half year, we had an English documentation. This documentation was in Docbook, so it was easy to take it and to translate it. And we need only two months to translate it completely with eight persons. It's a document with about 180 pages. It's a big document. And we finally released this document one week before such was released. So this is not the way to do it. It's not the way. It's not, it's really not the way. We had to find other ways because the English, at the moment, in Skolinino, there's too little number of English Skolinino installations. There's no interest. And, well, this was the reason. And I will start it with the weekend. If there's no machine, I will find somebody. We will have it in five years, I'm sure. And to challenge this with Japanese, wow! To get it with Japanese would really nice. It's very interesting. I have also an interest about such monitoring eyes, handling such monitoring eyes document. So, yes, the most biggest project would be Wikipedia, I think. It seems very not so related to other languages. You talked about, you use two weeks for different languages. It is a, just it is a way to solve the problem. So, I usually consider about, I want to, our information such as monitoring eyes, they should support it with, like, Wikipedia with language property. So, such system would be nice for purpose, I think. We have built a parser to take the Wiki pages to DocBook. And we have constructed also a parser who translates the DocBook files into Wiki. So, we just started to have it really easy because the Wiki has a low entry barrier. You have not, you know, not to have much knowledge to join the group to help. But if you want to learn for edit and DocBook, and so you have to learn all this, and HTML to do the documentation, you will never do it. And now the developers are not interested in documentation. It's a law. It's a law, computer or something. It's very interesting. In the demo page, it should be, the English page will be a master. Yeah, always, yeah. But if the master is not at home, what are you doing here? If there is no master? I usually try to write English first, but it's very hard. For me too. To me, this sounds exactly like the transition of the distributed version control. Essentially what you need is a structured editor or something like that, that supports the version control and can show you which paragraphs have been changed. I saw some system here, CISU. I don't know if you know it, about CISU, S-E-S-I-S-U, CISU. It is able to build an index about every paragraph and then it builds a hash about every paragraph. So if the little paragraph is changed, you will get a message. It's used from a lawyer to a big theoretical document. You see that? I can bring you to the guy who is developing this. He has uploaded it to Davion yesterday. I thought he was my neighbor and I thought, hey, what are you doing? So perhaps it's able to use this system. But maybe this system will not be able to use the whole documentation because you will receive a message every time when some translator fixes a typo in paragraph. Very interesting. Let me see. There's a German wiki about school unions. These are 1,400 and something pages. I have subscribed all pages. And you say, oh, you get such a huge of me, now it isn't. No, it isn't. It is possible to subscribe again. There's not so much change that you will be overloaded. It's working. But it will still be used from then such a digital system to have tags so you can see the same changes Yes. The big challenge is to have a structure and how to handle a structure. If there's a new point, it should be big. So that another person could find it. So I can talk to you. As far as I know, this room will be empty after that. Yes. Could you continue the discussion? It seems to be at a little point. Absolutely. Okay, so sorry for interrupting. I just want to thank my coolly son for his interesting talk. Sorry, but I need to go away. Continue your discussion if you like. Is there a son in your body who is being bullied who has a school in the neighborhood and who wants to enroll in high school in Linnards? I would like it. Then he will make the question in English and then he can go for it. What about schools in your country? They are all using free software. They have a lot of money also. They have the newest computer and a lot of money. How is it in your country? No, Italian schools are not that rich. You are directly connected to Garascogli. But he is sucking money. He is taking it away. They have not that much money. Anyway, there are per case system administrators who take their way to Linnards. I've heard somebody who is 1000 years old never heard about school in Linnards. That's the reason why I'm here. You hear about school in Linnards. It's important to have the skills. If you don't go with free software in schools, you can't forget it. You will last 30 years more. In your country, where do you come from? From Germany. From Germany? I know the situation. The teachers are not able to even to work as windows and they are surely not able to work as windows. I tried once in a school and they were not able to reboot the server if they had a problem. So they had to do nothing on it. Which does the government need? I'm from Germany too. From Germany too, I don't know. Where are the English people? No, they are from the United States. No, I don't know. Where are they from the United States? I thought the most developed ones are from the United States, isn't it? Yeah, always. They are sleeping now. Perhaps they are sleeping now. You are coming from? Sweden. From Sweden. And you from? Sweden too. Sweden too? You? You're praying. You're praying. Okay. From January. By the way, I need to translate and the Swedish translation is not ready for two pages only our flyer for school in New Zealand Italian and Nico said, I will do it out of here, man. He saw his wife and then he was lost. So perhaps you can do it today. I can take it with me. Sure. You really have it. Would be nice. If you could give me your view. I'll send you the source code and open office. I'll pass some slides in here. I'll be back. I'll put it in the web. I know flying in translation would be very nice. I don't like translation. You don't like translation? What are you doing now? Your talk was senseless because you don't like translation. What are you doing now? What do you like? Consider one of my packages that become template and translated in Italy.