PulkoMandy's blog

Haiku locale kit: the translator handbook

Blog post by PulkoMandy on Thu, 2009-09-24 21:49

GSoC is now over. It was quite fun to work with Haiku this summer, I learnt a lot of things, I gained commit access, and soon I'll have a new TShirt to wear :)

After the alpha release, the locale kit was merged back into the trunk. Of course, as soon as this was done I got flooded with bug reports, ranging from build breakage on freebsd to lack of grist in the jamfiles making the catalogs mix up between apps. As far as I know, both of these are now fixed, but there is still a problem when building from Dano and the bluetooth preflet doesn't want to be localized.

Locale kit : building a preflet

Blog post by PulkoMandy on Sun, 2009-08-09 22:15

The end of GSoC is in less than two weeks now, so it's time to clean things up and get what I started working. I spent the previous week reading ICU documentation to understand how it worked, and this week I used this information to build the locale preflet.

This is not as simple as it looks. First, I had no experience of programming with the Interface kit so I had to learn how things worked. I also had to modify some of the Locale Kit API to be able to actually change some things that were read-only. Finally, the preflet is also the first application using the date and time formatting part of the locale kit, which was not written yet. I had to both make the API work and make it configurable.

To do that I decided to call ICU directly in the preference panel, bypassing the usual API provided by the locale kit. This will be cleaned up later.

I'm still messing with the layout manager to get things looking right. Designing and coding UIs is not my favorite activity, I prefer messing with the internal of the system.

To design this panel I took inspiration from other OS, most notably Geoworks Ensemble (an old GUI from the ms-dos times) and Mac Os X.

International settings of some other OS

These use roughly the same system, a mix of dropdown menus and text fields, to allow the user to do almost anything with the date format, while still being readable. Windows allow only to enter a string using special chars such as Y for year. While this would have been simpler to code (ICU use such strings internally), I find it much less useable. My preflet also provide a realtime updated example of the current settings. The code is far from complete, for now it's only possible to select one of the default settings in the listview. The dropdowns are not filled in with the format info. The examples are working fine.

The other tab of the preflet is fully finished however. It allows you to select the preferred languages for localisation of texts. It's very simple, with only two lists and you can drag and drop languages between them to enable or disable them. You can also drag languages up and down to sort them by order of preference.

Locale preflet prototypeLocale preflet prototype

I'm tired of messing with scrollviews, tabviews and grouplayoutbuilders, so I will focus on the string parsing part and let the interface cleanup for later. I'd like to at least finish GSoC with something useable, even if not perfect, than a good-looking window that is useless.

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.

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 :)

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