Closed milnet92 closed 2 months ago
@milnet92 - should it be the same as Visual Studio? I think a typical settings, you have a Visual studio in English and D365FO client in your local language. Is it like this? So the language of the tool should be in pair with Visual Studio, no matter what language your client is, return errors in English
That's right, Visual Studio report errors in english only (and for X++ only) but the development and execution phase occurs in different application (VS vs browser) and in different times, runtime errors are localized and syntax / compile errors are not. However, in MXT both occur in the same place (browser) and seeing error messages in different languages makes it confusing, specially if it's a runtime error raised by the interpreter.
Anyway, resource files for user messages is something that has to be done, localizing them is just an extra step that can be executed after and It's quite simple!. Maybe I'll do the resource file part and let others do the translations later, also adding a new parameter to let the user decide if they want to keep interpreter's errors in local or not.
Just to save myself, I don't condone writing code other than English, but a lot of people do!
Errors that are reported by the interpreted are currently in English (US), but the tool is localized also for Spanish. A resource file(s) will need to be created for the interpreter and localize based on the culture or language of the environment that is being executed. Most likely the language can be obtained using the intrinsical Xpp proxy already present?