gsoc

Locale Kit : ICU integration on the way

Blog post by PulkoMandy on Sat, 2009-07-25 14:46

Locale Kit Interfacing with ICULocale Kit Interfacing with ICU

This week two important things happened for my GSoC project: I got commit access to Haiku and I finished working on the catalog part. This mean I can now work more efficiently without having to send my patches trough the GSoC mailing list (you may have noticed I still need my code to be reviewed, however :/).

The catalogs allow strings in an application to be translated. At a first glance you may think this is the only needed thing in a Locale Kit and my work is finished, but it is not the case. The first missing part is the preflet allowing you to select your favorite language. The locale kit will now always try French, if not found default to German, then finally to English. I think this is not the setup most of you want to use.

ZeroConf Support Progress

Blog post by majie on Mon, 2009-07-20 16:33

Hi guys.

Sorry for no update in the previous weeks.

I'v made some progress. mDNSResponder, which provides the underlying ZeroConf functionalities, has been ported to Haiku. It runs on Haiku correctly. In order to make it run, minor updates in our network stack were also applied.

I'm currently working on the service browser. It is almost finished. I'm also trying to write some wrapper classes so developers who need ZeroConf features can easily use them. And my mentor Axel is working on an update to our DNS resolver. After the update we will write some code that can resolve ".local" domains. So in the future you can directly type "http://webserver.local/" in your Web browser. Without any configuration it will resolve it and take you there.

OK. Stop here. Thank you. :-)

Locale kit: quick developer guide

Blog post by PulkoMandy on Thu, 2009-07-16 16:36
This week I was at the RMLL in Nantes, and I was busy showing Haiku to other people and explaining them why it was so much better than linux. I had little time for GSoC coding. Still, I made some cleanup and fixed some small bugs. The catalog part of the locale kit is now working fine and can be used to internationalize applications. Here is a small guide for those who want to get an application speaking in their own language.

Sourcecode changes

You have to alter your source code to get it working. We've tried to make this need as little changes as possible. First, you have to #include two files : Catalog.h and Locale.h. They are system headers from the locale kit. Now you have to tell the locale kit to initialize a catalog for you. A catalog is a class that you will use to map strings to their translated equivalents. The locale kit will automatically find the right data files for you, depending on the system-wide language preferences, you application mime signature, and some other magic (see the part of this post about the build system changes). So, you only have to add two lines of code:
BCatalog cat;
be_locale->GetAppCatalog(&cat);

Locale kit: cross tools, messing with jamfiles

Blog post by PulkoMandy on Sun, 2009-07-05 21:29

This week i've been working on a big red post-it that was on last week's picture. It was about wo things : make the catalog handling tools work as build tools, and test them in some special cases.

The first part took me almost the whole week. I started doing a full port of the locale kit, but noticed it would probably be too complex to do that. Instead, I started over with a simpler solution. I only compiled the tools I needed, statically including the catalog add-ons inside them. It is now possible to extract the keys (original string) from a BeOS program, translate them to a new language, and integrate them in the Haiku Image. I did not have much problems with C++, but Jam caused me some difficulties, as I had never worked with it before except copypasting things around to integrate my code to the haiku image. This time I had to build up a new part of th toolchain, creating two rules and two actions. Ingo helped me a lot on that and now I have a better understanding of the whole Jam system. The rules I wrote are still not perfect, there are already some plans to make them simpler to use.

The second part of the post-it was about checking if collectcatkeys could extract strings correctly from sourcecode if they contained escape characters (\", \n, \t). Of course, that did not work at all. The problem is that we have to remove these escaped characters at some point and replace \t by tab, \n by newline. gcc will do that when compiling something, so if the program asks us to translate a string, we have to have it in unescaped form. This is currently done in collectcatkeys. But the change I made to collectcatkeys make it save the extracted string in a simple text file, and worse, I use tabs as delimiters. So this unescaping work will have to be done in linkcatkeys instead. This way, it is possible to translate the string easily, and then it is converted so the program will still find it back after compilation.

So, work for next week will start with a cleanup of my jam rules if I manage to do it (I'm still not very skilled at Jam), and fix of this quite important bug. But, next week I will be at the RMLL with some other Haiku developpers, so I'm not sure I will have much free time for coding. Well, there will be at least the hours I will spent in the train to go there.

Also, Oliver has made good progress on the wchar_t fixes. So I'm getting ready for messing with ICU and integrating it in the API. First step will be to build it with the new wchar-fixed gcc, then to make sure the tests are working ok before I do any integration work.

Finally, I also plan on making the Locale Preflet the first fully localized application in Haiku. This will allow me to test the catalog part and some other features such as the broadcast BMessage sent to all applications when the user change the default system language. The locale preflet will serve as a reference implementation of what to do when localizing an application.

Locale Kit: the big picture

Blog post by PulkoMandy on Sat, 2009-06-27 19:14

almost-UML diagram of the locale kitalmost-UML diagram of the locale kit

This week, I finally got the plaintext catalog add on working. Then today, Oliver reviewed my work and we had a meeting on IRC. We agreed on some changes to the internal architecture of the locale kit, and also to the classes I added. Some classes in this kit have unappropriate names, and the kit was designed with zeta compatibility in mind, whereas in today's Be-World it seems more important to focus on gettext. I summarized our meeting in this somewhat-UML diagram. It's not really an UML object diagram as I added informations about the workflow and the tools to use when working on a localized application, and a lot of notes and remarks. I think it shows well the status of the kit: a clearly designed API, but some missing code and a lot of TODO notes. I did not fully reported the parameters of the methods and the attributes of all the classes, look at the headers if you need some information on that. This diagram is not meant as a technical reference, but as a colourful and efficient way of cleaning up my personal notes. I think I'm better at organizing my tought in a spacial way than laying them down linearly in a text. Click on the image to enjoy it at full size :)

Another week down.

Blog post by bebop on Mon, 2009-06-22 10:10

Well another week has passed. I cannot say that to many eventful things have happened with my project. I have been working on getting all of the logic in DriveSetup to work the way I think that it should. I finally connected my development computer up to the network today though and thought I would post a screen shot. The two partitions were created with DriveSetup! Not a whole lot to look at but I pictures are always fun :)

DriveSetup Creating PartitionsDriveSetup Creating Partitions

Locale Kit: (somewhat) weekly report

Blog post by PulkoMandy on Fri, 2009-06-19 18:42

Mid-term evaluations for GSoC are already coming...

I'm still working on the catalogs for translating applications. I got the system working and integrated it into Haiku, so now any application can be translated. However, there is still a lot of work to do. I'm now working on a plaintext catalog add on.

Catalogs are the files that store translated strings. There is a catalog add-on called "default" that is used in applications. The problem is that the files for this add on are stored in binary form (as archived BMessages), so it's not easy to translate them.

So, the plaintext catalog add-on will allow developers to extract strings from their source programs and easily translate them in a plain text file. Then it will be possible to convert it to a binary file for use in the application. This is simpler to code than a full featured translation tool (that may come later), and also allow testing of the add-on system.

This is about everything for the catalog system, the other part of the work on this project is the formatting toolkit with functions for formatting dates, times, and numbers. This should be done using ICU, a library that provides all the needed classes, but will be wrapped in the already designed Locale Kit API, which feels more in accordance with the rest of the BeAPI. ICU will also be used to manage a big part of the preflet : language listing, and mapping languages to presets for all the settings.

The last part of the project will be mostly centered on the preflet. It will have to send a message to all the application when the user select a different language, so all the opened window are refreshed automagically.

I have a little problem with my debian setup this week, and for now I can't build haiku under debian anymore. But I will try to build directly under haiku if possible to keep working.
Also, I just finished school exams last week, so from now I will have a lot more free time and I hope the project will speed up a lot.

Syndicate content