conv-ml
December 20th, 2011
The last few days, I’ve been working on something that was long overdue: making our solution fully multi-language (ML) aware. Until now, there has not been much use in doing so, since we cater exclusively to Dutch-speaking customers. As we are preparing for the Certified for Microsoft Dynamics certification, however, ML-readiness has become more important.
My first step was to convert (relevant - see below) hard-coded text in the C/AL code to text constants, using conv-ml. Below, you’ll find my experiences.
First of all, I needed to find the ML conversion tools. Luckily, the NAVW14.00 UPGTK is available for download from www.mibuso.com, saving me some time that would otherwise have been spent looking for old product CDs. Please note that conv-ml contains 16-bit components. Windows 7 does not support these, but does come with a VirtualPC-based solution for running in Windows XP compatibility mode.
The syntax for running conv-ml is quite straight-forward:
conv-ml {source.txt} {target.txt} {translation.txt} {idoffset} {languagecode} {languageid}
- {source.txt} is a text export file containing the source objects;
- conv-ml writes its output to {target.txt};
- {translation.txt} should contain a translation export of the source objects;
- created text constants are named “Text”, followed by the first available ID greater than {idoffset};
- hard-coded text currently in the objects is assumed to be in the language represented by {languagecode} (3-letter code) and {languageid} (numerical code); only text constant values for this language are created.
In my case, the command line read:
conv-ml source.txt target.txt translation.txt 11024000 NLD 1043
Make sure the old hard-coded text is in fact in the language specified in {languagecode}/{languageid}, or you’ll end up with very confusing results.
Thanks to {translation.txt}, conv-ml knows which text constant names already exist, and will avoid naming conflicts. Generated text constants do not yet have a UID (Unique ID). They will not be assigned until the objects from {target.txt} are imported into a database and compiled.
It’s important not to create too many text constants - not every bit of hard-coded text is a candidate for text constant conversion.
- In our solution, date formula constants (e.g. ‘<CM+1D>’) form the largest category of falsely converted hard-coded text. I’m reverting them to their previous form (making sure they are properly ML-aware by surrounding them with “<” and “>”), and deleting the corresponding text constants. There must be a cleverer way to do this…
- File format specific information, such as XML element names in file exports, are non-translatable either and should remain hard-coded.
- Finally, please note that conv-ml is quite eager to convert strings - commented out hard-coded text or even text between single quotes in the Documentation section is converted, and should be reverted manually.
Please be so kind as to share your own conv-ml experiences in the Comments section! 
December 28th, 2011 at 3:30 pm
No need to use a virtual machine. I am using dosbox (http://www.dosbox.com/download.php?main=1)
I even virtualized it using VMWare Thinapp and it works fine.
December 28th, 2011 at 8:58 pm
Thanks for your response, Alain.
I was in a bit of a hurry, and didn’t want to have to install anything unless strictly necessary. It turned out the Windows XP compatibility mode did the trick!
December 29th, 2011 at 3:16 pm
But for people, like me, that don’t use Windows 7 but Windows Server 2008 (R2), this is workaround for avoiding having to run it in a VM with XP.
December 29th, 2011 at 4:57 pm
Fair point! Thx!
January 16th, 2012 at 11:47 pm
This seems like a serious candidate for a rewrite from someone in the community. Perhaps I’ll add that to my list of other projects I’m not working on nearly as much as I should.
January 17th, 2012 at 12:12 am
Thanks for your response, Thad. Do you mean in order to come up with a 32/64-bits port of conv-ml, or in order to work around the limitations described above? It will be quite difficult to intelligently decide what to convert, and what to leave alone, I think?
January 17th, 2012 at 10:37 pm
I mean to come up with a 32/64 bit version but also perhaps a tool that works even better. I actually don’t think it would be that bad to make something that would do a better job of picking which strings to turn into ML constants. I’ve never used or looked at the conv-ml tool but from the descriptions it seems simple enough. I could use my object parser lib to chew through the objects and then my C/AL tokenizer could identify and build a list of the strings inside the code. Then it would be easy enough to present the user with a list of all the strings identified with a checkbox to specify whether it should be converted into a constant. I could even provide the ability to specify default rules in the form of regular expressions as to whether a string should be converted. This would make it fairly easy to identify date formulas. What do you think?
January 17th, 2012 at 10:42 pm
Sounds good.
However, I’m not sure how much time one should invest in conv-ml at this point. Most add-ons should be multi-language-enabled by now, right?
January 18th, 2012 at 6:56 pm
I would hope so, but I’m sure refactoring strings into constants is generally still something many people could use. Even if someone isn’t planning to support multiple languages perhaps they’d want to do it just for good design principles. I know I have a bad habit of banging out strings in my code and then going back later to change them to constants.
January 18th, 2012 at 9:13 pm
February 29th, 2012 at 12:49 pm
In fact almost all these ML (Multilanguage eneabling) tool that were concived ages ago are still very useful tools (se also my blog post http://dynamicsuser.net/blogs/vanvugt/archive/2010/02/28/quot-where-used-quot-as-simple-as-you-can-get-it.aspx).
Indeed they’re old fashioned, but still …