Al: Translations request

[LauraNicolas]

Hello,

I am testing the XLIFF translations and they are great.
I have a request to make it easier for developers to add translations "on-the-fly"

Labels , Captions, etc. could use the Comment tag (or better to have a ML tag) to insert translations.
When the XLIFF file is generated, it could use the new tag and:

• Create the "original" xliff file (already done)
• Create a new xliff file per language found in the code.
• Put the translated text between <target></target>

Many thanks for considering this feature for new releases.

Salut!
Laura Nicolàs

[Gallimathias]

I don't like the idea. On the one hand, this is a backward step more towards hard-coded translations and on the other hand, it is a bad design to use comments for multi language file generating.

Yes, it would be nice to make the comment function usable for XLIFF files, but it should not be used to generate files but to keep exactly what it is. A comment.

Those who want to have such functionalities should rather rely on appropriate translation tools.

[Kungitoo]

Hi @LauraNicolas . Are you sure you want to pack the other translations in source code or is this just a way for you to convert your code from ML to Label syntax?

[LauraNicolas]

@Gallimathias -- It is bad to use the Comments tag. I know. A ML tag would be much better.

this is a backward step more towards hard-coded translations

This is not harcoded. The system will always use the .xliff file.
This is a way to help building the .xliff file faster.

@DominikDitoIvosevic

is this just a way for you to convert your code from ML to Label syntax?

No, I am not converting code. My suggestion is for new developments.

This is the scenario:
A developer is creating an extension as a customization (just for one customer).
The extension is not going to be translated to multiple languages. Just the one of the customer (non english).
There is not going to be any external resource doing the translations. The developer will do it.

Having to do all the development, and then handle the translations, just adds extra workload.
It is while developing that we have the most contextual information to decide the better translation.

To me it is great to have translations in a separate file. I am just requesting an extra help to create the .xliff files for the non en-US languages.

I hope this clarifies it.

[Gallimathias]

@LauraNicolas It is hard coded especially when you introduce an ML tag that we just got rid of. Ultimately, whether comment or new keyword it is in the code and if you don't want to have it any longer, you have to change the code to remove it.

Today's old and uneffectiv processes seems comfortable, they trained by the historical technical constraints. But with such a request, the question generally arises as to whether it makes sense to produce the translation already during development. With regard to the translation quality of many products and adaptations, I don't think so.

From a time factor point of view, I don't see that it is faster than having my template, which generates AL, automatically processed by a tool. On the other hand, if I look at the previous XLIFF tools which exist there would be a production of already specified language files in the run-up rather counterproductive.

If you work with it longer you will see what I mean and that there is no ML tag needed as it used to be.

Maybe we could add an optional prop in the launch that already creates templates for each language. I do not want to introduce an ML tag or extract the comment.

[LauraNicolas]

If you work with it longer you will see what I mean and that there is no ML tag needed as it used to be.

I agree. Not as it used to be.
In C/SIDE the translation had to exist in the CaptionML property. There was no other way.
I am suggesting to add a ML tag only to help build the .xliff file.
If the ML tag is empty or a translator has decided to changed a "proposed translation" it shouldn't matter: The only text that the system has to consider in the UI is the one in the .xliff file.

With regard to the translation quality of many products and adaptations, I don't think so.

I am native in Spanish. You are asking me (or any other developer not native in English) to write all texts in English first (in the code) and then to give someone else the .xliff files to handle the translation to my own native language.
It just doesn't make any sense.

I am much better at Spanish than at English. For me (and many others) it should actually be the other way around: write it in my native language first, and then let an specialist do the English translation.

From a time factor point of view, I don't see that it is faster than having my template, which generates AL, automatically processed by a tool.

I think I am missing something here... what template are you talking about?

Ultimately, whether comment or new keyword it is in the code and if you don't want to have it any longer, you have to change the code to remove it.

Right. The same happens in the English language. If someone changes the translation file because there is a mistake in one of the texts... you have to go back and change it in the code. Or not... because the UI will only show the text in the .xliff file...

You cannot assume that in English it will be well written in the code, but not in any other language.

I agree that if there was a translation quality in the past is because the developer had to handle it, and it was difficult to leave it to non-technicals.

Now this problem is away. I will not try to translate my extension to French or German. I will handle the .xliff files to an specialist. So it is great that we now have this option!
But it is different with my native language. I will do those, and I need it to be easy.

@Gallimathias I really appreciate your comments, because this makes me think it further. Many thanks for that.

Salut!
Laura Nicolàs

[Gallimathias]

@LauraNicolas

I am native in Spanish. You are asking me (or any other developer not native in English) to write all texts in English first (in the code) and then to give someone else the .xliff files to handle the translation to my own native language.

Yes, I expect a developer to speak English. At least something. The code is english and in addition to the neutrality I think that you should also comment in english etc. This discussion has been going on for a long time. I see the translation property as a fallback if there is no xliff file and as a hint for the xliff editing so this translation only needs to be of sufficient quality.

I am much better at Spanish than at English. For me (and many others) it should actually be the other way around: write it in my native language first, and then let an specialist do the English translation.

I think I am missing something here... what template are you talking about?

As it is with you, it has also been with us so far. You program and briefly make the caption. However, I think that you should take more time for UI texts in the context of quality improvement. While someone coded it can be that he changes the code several times or that he names things differently than another developer. Or a developer makes more effort than another developer. And what kind of designation does the customer really want? Experience shows that this happens quite often and is language independent. The result, however, is a mix of designations which gives a worse user experience for the customer, regardless of whether it is a foreign language or a native language. Therefore, I think you should do your translation phase after the programming phase. There you have an overview of all terms or a tool in your hand which helps you. And the Code is more stable because the programming is finish. In accordance with the motto first of all make sure that it runs then that it looks good.

If you get one of the big XLIFF tools, you can see they use a template. The XLIFF created by AL himself I see as such a template. This file does not contain any target language and will be overwritten with every build.

Good XLIFF tools or the big XLIFF tools I've seen take such an empty XLIFF file and copy the file for each new language. Each time you create a new file, these tools can easily detect the changes and apply them to all other files.

If you take a look at the example here, you can see that a translation has been created especially for english and that the source file has remained the same. Overall, this procedure is extremely convenient. You realize that with such a procedure it is possible to work in parallel.

Get Address Service.g.xlf AL generated file with no translation
de.xlf German translation
en.xlf English translation

Right. The same happens in the English language. If someone changes the translation file because there is a mistake in one of the texts... you have to go back and change it in the code. Or not... because the UI will only show the text in the .xliff file...

Yes, they are partly right. The difference is only that even if a developer at the thing was that xlif can still be consulted by someone else. On the other hand, if you use e. g. git it is much more pleasant to see the changes only on the xliffs. In addition it was already desired and also here by the ms developers testified that at some time also App's will possible that only contains XLIFF files for other App's. i. e. one will be able to modularize in the future very beautifully. And then there is really no need to rebuild the app for language adaptations.

I really appreciate your comments, because this makes me think it further. Many thanks for that.

That's what community is for ;)

[LauraNicolas]

Hello,

Many thanks for your answer.

However, I think that you should take more time for UI texts in the context of quality improvement. While someone coded it can be that he changes the code several times or that he names things differently than another developer.

I agree. And I see it when you are developing an extension with the intention to be massively implemented.
Customizations, on the other hand, should be easier to develop. They are ment to one single customer and he has to pay for the full cost of it. You need a viable product, not a perfect product. I don't see customizations going after a translation process, but just using the texts that the developer wrote.

I have to admit that the template part makes a lot of sense.
This way you are not assuming that the text in the code is the one going to be used for the ENU language, but a UI expert/translator will review it.

You can take the same approach with any other languages: use a ML tag, let the developer write it in another language, and treat it as a template.

And... if the ML tag is empty, no problem: send the xliff file and get a translator to do the job.

In addition it was already desired and also here by the ms developers testified that at some time also App's will possible that only contains XLIFF files for other App's. i. e. one will be able to modularize in the future very beautifully

This is very good news. Thanks for sharing.

Salut!
Laura Nicolàs

[Gallimathias]

You can take the same approach with any other languages: use a ML tag, let the developer write it in another language, and treat it as a template.

An XLIFF file always has one source and one target language. It does not make sense to have multiple source languages with different files.

Even if I only do individualization for a customer. Even though I don't use a translator. Or I'm the only developer of the company, or i'm the only employee of the company. It makes sense to separate translation and development. During the programming phase I want to develop and not translate. As a developer, I would only be satisfied with the field names I give away. Even for quick and dirty adaptations, it makes sense to think about designations either before or after programming, preferably in cooperation with the customer. It is also annoying because the caption property can be inherited from pages in the tables.

You can continue your work to the motto, "Fast and cheap" or "as long as it works now what comes later doesn't matter". But I'm convinced that a ML keyword, optional or not optional, in the programming language will degrade the code quality and thus the product quality. However, it is in the interest of all users, customers, Mircosoft and partners that the product and code quality is improved.

I still maintain my point of view that a return to an ML prop in its entirety is a very bad decision. I think that the only reason for the wish is that it is not comfortable to change the own habits. For me, however, quality in software development is definitely above the convenience of a few.

But feel free to realize your wish with a own tool. Extracting ML tags from comments or temporarily adding something else to the AL syntax should not be a big deal for a developer.

I now believe that our two positions are well known. ^^

The bottom line is that the decision about the ML keyword is not up to me or you. Microsoft is responsible for deciding on the reintroduction of an ML property.

[StanislawStempin]

Keep in mind that if you're building an app for one non-English language then your original label text doesn't have to be in English but simply in your target language. Then you just copy the generated XLIFF and market it for the right target language.

[jglathe]

Well. I'm not entirely sure that pulling the discussion into the quality domain is the best of ideas. @LauraNicolas has a point, IMO. If you happen to come up with translations as you write the code, it should be possible to write them down, preferably without leaving the programming context you are in. Let the environment handle the splitting into separate files where needed. So... I would prefer to have either the compiler or the editor handle this, if you happen to write translations (as ML properties, why not). The editor could also rebuild them from the translation files if wanted. The point is that it should not be a context switch for the developer who happens to come up with (however useful) translations, as all of the more experienced ones do. It should just work.

[Gallimathias]

I think it is a question of quality @jglathe .

If the experienced developers do it, then this may sometimes be useful when you ask the experienced developers, but actually happens out of habitualness because they've done it before and befor and befor. You can see the result today.

If you want to have such a function, Create translations during development without leaving the development environment, then such a function should be a task of the development environment and should not lie within the area of responsibility of the language. I think programming language should be neutral, an ML property is the wrong way.

And if you need something like that because you want to work as before, you can simply extend VS code with a extension. Why has to adapt the language for such a functionality? The displayed language should not be totally dependent on logic.

[jglathe]

Whatever doesn't force a context switch for the coder. It shouldn't prevent entering a translation, even if it's only a hint for the real translator.

[Gallimathias]

Properties for notes for the correct translator, or if you translate later in the translation phase yourself, already exist.

The Comment and Caption Property ;)

[Kungitoo]

Thank you everyone for sharing you opinions on this. It helps us get a clear picture of how our tool is used. Right now, while I'm not in favor of the approach of tying back multiple languages to the source file, I can see the real world benefit for a specific development scenario.
I hope that you understand that if we added some way of doing this in the compiler, it definitively wouldn't feel nice. It would be a hacky way to support multiple translations.

What I suggest to you is to write a simple script which you can use to update your translations when you want to. You can use the developer comment to write alternative translations and then a simple powershell script which copies the file and replaces the target value with the one from the comment. It would be less than 10 lines and would cover your scenario

[LauraNicolas]

I had already thought about the PowerShell script. I will try it. Thanks Dominik.

[Kungitoo]

Thank you for the discussion. In case you have another related issue please open a new one