Up to some weeks ago I have always been convinced that it is absolutely not necessary to be able to edit the reference language from within the Localization Manager. This makes the process very clear: “We create all localizations from the reference files and only read those. We won’t touch them even if you’d want us to.”
However, this has changed. Some users came up to me and requested the ability to edit the english (reference) strings from the outside. They have their localizations sent to a professional agency and they tend to find typos in the english strings. Instead of them having to go into each file and look for the occurrence, they wanted to be able to import a mono-lingual strings file that came from the agency and automatically have their typos fixed.
Only very few may know, that solving this issue is quite an issue. The problem was that the Loc-Suite had only one dirty state for the reference language. But now we’d need two: when the contents in the file were modified, imported and need to be written to all other languages and when the reference language was changed in the database. As you might imagine, from a developers experience, splitting such a fundamental and central state is a very sensitive change. Luckily it was not overly much code to change, but still it was a lot of code to check that it worked right. Luckily I got unit tests 
The short message is: it’s in there. From the next nightly build on, you will be able to edit the reference language right from the Localization Manager. This function is not yet in the Localizer. Makes few sense there, I think — send me a message if you feel you need this.
When you now have a look at the change status of your files in the manager, you might get a a little cumbersome picture:
This means that the reference language was changed in two ways: the file was modified and the changes have been imported (thus the “Reference”) and the developer edited some of the strings in the Manager (thus the “English”). What will happen now? As the reference changed, first all other languages will be written. After that is finished, the reference file will be updated and immediately rescanned again. The rescan is more or less a security and convenience concern.
That’s it for today. Have a nice weekend!
Max
Just today, I have finished a great series of nice new features around dictionaries in the Localization Manager. So here it goes:
- First, of course, you can open and load dictionaries and files like it’s in Localizer. This is needed for the following features.
- Trivially, this enables support for automatic translation. While the best place to do this is still the Localizer, you are now able to automatically translate files in the Manager as well. This may come in quite handy when you split up a interface file and want to transfer the strings from one to the other.
- Next up are embedded dictionaries. Having loaded dictionaries in the manager enables the ability to include tailored — embedded — dictionaries in exported Localizer files. This reduces the need to ship dictionaries separately and comes in handy especially when the developer wants to ensure consistency. So embedding the system glossaries and the one of your old version will ensure maximum consistency. Additionally, these embedded dictionary will contain keys that match only. This has two benefits: first the dictionary will be smaller and thus the file, and second, you do not transfer your complete knowledge base. The translator could “steal” (i.e. copy it and keep it as his own) the dictionary, so you will want to keep it as small as possible.
- One thing else that can be done when having dictionaries, is calculating statistics. I am very proud to present the (like version 2.0) updated statistics panel:
Not only that the sections are collapsible and nicely animated (yay), the major new thing is the third part. As you can see, there are detailed statistics about the selected keys in relation to your knowledge base. This is especially interesting for professional translators to estimate their work and calculate the price for a translation. Counts are being given in key pairs and words.
That’s the main thing. I also fixed several bugs (see commit log for details) and added export and import facilities to the Localizer. This enables Localizers to save their work done to a dictionary in order to not loose any data. And this allows agencies to work on Localizer files, but to export the actual translation work to XLIFF and reimport it later. Flexibility as it ought to be (at least in my opinion)!
I’d love to get some feedback.
BTW: These things are online right now. Have a look in the nightly trunk.
Today I can proudly announce another nice new feature in the Loc-Suite: Segmentation. Basically this is the process of splitting a longer string into multiple parts. Examples for segmentation are paragraphs, sentences or words. I’ve implemented this functionality in form of an engine in the frameworks.
Currently there are two usages: First, the matching. While this piece of functionality used to have it’s own (admittedly quite limited) segmentation, it is now using the new one from the framework. This changed nothing when looking at the features, except that the code is now well-tested and more reliable.
The second usage is in Localizer. Splitting longer strings into shorter ones eases the localization process and also increases the probability of finding matching strings. Thus, Localizer now features a filter setting for segmentation by either sentences and paragraphs.
Segmentation in Localizer will be available in tomorrow’s nightly build.
It must have been nearly a year since I have been posting about the Localization Dictionary and that it will get made up very soon. Soooo now has finally the day come to announce that I made it. Here’s a little screenshot: (yeha)
There are a few significant changes. Here are the major features/changes:
- Imports .lod, .ldb, .loc, .ad and .xlf files!
- Dictionaries can be limited to some languages
- Normalization on a language to reduce size
- Very fast file import, many performance improvements
- Searching finally works
And so on… Next up in a few days is exporting – to TMX and as Dictionary. Read you soon!
Just a quick update on what has happened recently: I added support for both the XLIFF (XML Localization Interchange File Format 1.2) and the TMX (Translation Memory eXchange 1.4) standards to the framework. This now allows developers on a Mac to exchange a localization project using XLIFF, as well enables translators and localizers to use their existing glossaries using TMX. A nice side note: as the standards for both formats support embedded RTF content, the Localization Suite added this support as well.
If you get the latest nightly build of the Localization Manager, a new export and import command for XLIFF will have appeared. The support for TMX is not yet visible, as this will be available in Localization Dictionary only. Therefor, I will have to finally make the app work again – which I am doing right now. So stay tuned.
BTW: The recent nightly builds also sport a set of bug fixes and minor improvements to make things work a bit smoother. An update via Sparkle will hopefully come soon.
Have a nice weekend, Max
Yes, it happened. Just a few minutes ago my algorithm worked for the first time — adjusting a user interface completely autonomous using automatically generated structure, constraints and so on. While the thing is FAR from finished and while any further details about the algorithm and so on will have to wait for later, I want to share two pictures with you. They don’t look any spectacular — but keep in mind that after changing the title of the one button, the complete resizing has been done autonomously. A thing you can easily see: the buttons still have the same size and the same distances.
Before:
After:
For those not yet knowing: I am working on a thesis about automatic resizing of user interfaces during localization. Keep the applause coming…
And if there’s a good news item having a #1, there must be a number 2. And here it goes: The fine boys over at wordcrafts in Flensburg (as well Germany) will do the documentation for the Localization Suite. This is an incredible value and I am very pleased by them doing so.
For those who are not yet familiar with wordcrafts: they are top experts in regards of localization and documentation, able to deliver quality translations in a reliable, timely manner. And having documentation pros doing my documentation seems to be far beyond anything I could have done on my own — kudos for that!
My call for icons just before christmas must have been very well received. I got multiple offers to create a nicely looking set. So here comes my great great greatest thanks to the guys over at Boinx for having their designer do the hard work!
For those of you having not yet had the chance to meet them in Munich or at the WWDC, let you be told these are awesome developers doing amazing software — and the most important: localizing it with the Loc-Suite. Again, my thanks for helping me out on a problem that has been bugging me for at least four (in numbers: 4) years!
I finally managed to register the Loc-Suite at Twitter so you all can follow the development quite easily! Find me at @twitter!
As the version 3 is finally emerging toward a very nice state, there’s still one thing that is disturbing me since a very long time: the current set of icons. They are a mix of various different design attempts, all either failed or canceled. This is why I am writing to you:
I’m looking for someone who wants to create or donate a nice set of icons for these tools. Basically it’s three application icons and each with an according document icon. That’s all.
If you want to donate some money to the project, this would be a very good thing to do! Drop me a line at max [at] loc-suite [dot] org and let me know if you have any interest!
Thanks, Max
