crs-al-language-extension
crs-al-language-extension copied to clipboard
Translations - Fix ML-properties to new translation file
Scope
- Other languages will be deleted
- ML-properties will be replaced by the new syntax
Do you have any thoughts on how to implement this? The ML properties is now banned when validating your app on appsource in favor of XLIFF, so a lot of users will need this one. Doing a manual migration from ML to XLIFF on a large extension will be very time consuming and error prone. Please let me know if/when you've got a time frame for this one, cause I know I will need this in some form. I might create a prototype later on if you don't have the time to... 🙂
I don't have time/deadlines, sorry :(.
Well, I was thinking of doing a simple find/replace, like:
- "CaptionML = ??? = " to "Caption = "
- "TextConst = ??? = " to "label "
- ...
And that for all ML properties on all files.
Additionally, I was thinking of a "find" function as well - to report all ML properties "some" way. Then again, if you just commit before you would execute this .. it's all reported in SCM.. .
Makes sense?
So much to do, so little time 😉 Yes, transforming the ML properties to the non-ML ones is the first step. Probably using the ENU caption as name (with some fallback if ENU is missing). The other thing needed is to move the translated texts to the xlf file, right? I need to take a deep dive into this, I realize... I'll report any progress here later when I get some time.
Well, the move to xlf is really something I don't know is feasible, let alone interesting. Sure it's interesting, but there are many things to overcome if you want to do that.. . Would be nice though, but it was not in scope for this issue for me ... would be interested in your view ;-)
I've been looking a bit into how to generate XLF files, or at least navigate to the right place in an existing XLF file from an AL object. But I hit the wall when trying to figure out what hash MS is using for the object names. I found this post: https://www.yammer.com/dynamicsnavdev/threads/1002744300 that at least admits that there are a computed hash. Let's see if they can share the algoritm.
Without that one, we'll have a hard time to patch existing XLF files as well as creating new ones.