Prerequisites

• Visual Studio Code installed on your machine
• Node.js version 20.17.0 installed on your machine (other versions of Node will likely work as well)
• General understanding of navigation in Visual Studio Code IDE

Steps

1. Open Visual Studio Code and create an empty folder “LocalizationExampleJS”:
   
   
    
2. Add the file “LocalizationExample.js” at the top level of your new folder:
   
   
    
3. Add a new subfolder "Resources" with empty files “en-US.json”, “es-MX.json”, and “fr-FR.json”:
   
   
   
   
4. Add the following code to each JSON translation file. It’s important for the text keys in all 3 files to be identical – in this case, the sample text we are using has the key “HelloWorld”.

en-US.json

<code>
{
  "HelloWorld": "Hello World!"
}
es-MX.json
{
  "HelloWorld": "¡Hola Mundo!"
}
fr-FR.json
{
  "HelloWorld": "Bonjour le monde!"
}
</code>

<code>
{
  "HelloWorld": "Hello World!"
}
es-MX.json
{
  "HelloWorld": "¡Hola Mundo!"
}
fr-FR.json
{
  "HelloWorld": "Bonjour le monde!"
}
</code>

5. Add the following code to “LocalizationExample.js”. This will enable you to supply a command line argument containing your desired locale string during testing. (Note that in an actual web frontend solution, the frontend code would need to access the current user’s culture from the server, NOT via command line argument.)

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);
</code>

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);
</code>

6. Below the code to extract current culture from command line arguments, add the following code to access the “HelloWorld” string for the supplied culture. If a culture is supplied that is not present in the application, then an error message will log accordingly, and the application will default to the “en-US” locale.

<code>
var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

<code>
var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

7. Your code is ready for testing! It should look something like this:

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);

var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

<code>
const args = process.argv.slice(2);
const currentCulture = args[0];
console.log("Your supplied culture is: " + currentCulture);

var pathToJson = "./Resources/" + args[0] + ".json";
try {
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
catch (err) {
  console.log("Culture \"" + currentCulture + "\" does not exist in this application - using default locale en-US.")
  pathToJson = "./Resources/en-US.json";
  const jsonObj = require(pathToJson);
  console.log(jsonObj.HelloWorld);
}
</code>

8. Open a terminal and test out the LocalizationExample solution using the command node .\LocalizationExample.js xx-XX, where “xx-XX” is a locale string representing the combination of a language and a region. Try out “es-MX”, “fr-FR”, “en-US”, and “pt-BR” (Brazilian Portuguese) as command line arguments.
   
   Note that the HelloWorld resource for the cultures “en-US”, “es-MX”, and “fr-FR” all appear translated as expected. However, the “pt-BR” locale yields the HelloWorld string in English, because this culture is not present in the collection of translations, and our code explicitly defaults to the “en-US” U.S. English locale in this case.

Localization Tips and Tricks

When it comes to localization, there is a lot more to consider than simply translating text and accessing it appropriately from code. Read on to learn some tips and tricks for elevating your localization solution!

Text Key Organization

Generally, DMC has found that it is beneficial to organize text keys into separate files based not only on language, but also based on what page of your application the text belongs on. For backend localization, this is likely best done by splitting text by controller. Here is an example of a backend localization file structure that includes two controllers, “Login.cs” and “Home.cs”, and two cultures, a default culture and “es-MX”:

• Resources folder
  • Login folder
    • Login.resx
    • Login.es-MX.resx
  • Home folder
    • Home.resx
    • Home.es-MX.resx

This separation organizes your translated text in a way that is easily modifiable for each individual page of your application.

In the event that identical text appears in multiple places in your application in English, it is still beneficial to duplicate that text key/value entry across pages, rather than maintaining a single key/value item. For example, if the word “Email” exists on both the “Login” and “Home” pages in the example above, this text key/value should exist in both the “Login” resource files and “Home” resource files. This enables you to update the text in one place without modifying the same text elsewhere, if desired. Also, translations of the same English word or phrase could be different across different languages, depending on the context of how the word or phrase is used – in this case, separate text/key values are necessary for translators to appropriately translate your application text.

Variables and Pluralization

Variables and pluralization can be quite tricky to handle in any localization solution. For a backend solution with .resx files, if you have a sentence to translate with a variable in the middle, you need to separate any given string key/value into separate parts that precede and follow the variable.

For example, say you want to include the phrase “Hello, {name} – welcome to my site!” The following key/value structure would need to be implemented in each .resx file to handle this phrase:

Additionally, numeric variables add an extra layer of complexity to a localization solution, because pluralization must be implemented for these. The way words are pluralized can actually differ significantly across languages. For example, Slavic languages (e.g. Russian, Czech) have a different style of pluralization for 5 or more of an item than they do for zero, one, or 2-4 items. So a solution that translates to Slavic languages must implement separate logic for pluralizing 5+ items than for other items. For example, the sentence “You have {number} items in your cart!” may have a key/value structure like this in English:

As you can see, this is a complex case to translate for – there are 8 total key/value pairs to accommodate just one sentence that integrates a numeric variable. To avoid the need for this, one solution is to reduce or eliminate the need for accommodating plurals – for example, you could rephrase “You have {number} items in your cart!” to instead become “Number of Items in Cart: {number}”. This would only require one key/value pair to be translated instead of eight.

Fallback Cultures

When a user’s specific locale does not have a translation present in your application, it can be beneficial to implement fallback cultures so this user is given a more suitable approximation of their desired language. For example, say a Spanish speaker lives in Spain and therefore has their browser locale set to “es-ES”. However, your application only has resources for Mexican Spanish “es-MX”. Ideally this person in Spain would see the application in Mexican Spanish rather than the application default of English, because Mexican Spanish more closely matches their desired language than English does.

Using .NET backend localization, fallback cultures can be implemented by simply renaming any files ending in “es-MX.resx” to instead end in “es.resx”. Per .NET’s culture fallback scenarios, upon receiving a request from the Spain Spanish user, .NET will still search for “es-ES” first. But upon not finding this specific culture, .NET will “fall back” to just the “es” portion of the locale string and will access the text as it exists in this new general Spanish file. Users using Mexican Spanish “es-MX” will see the same behavior.

Common Pitfalls

Localization can be complicated, and there are some common pitfalls you may encounter if you are implementing your own localization solution. Here are some examples:

• Logging / error messaging: if you are displaying raw exception messages to your users, then these are not able to be localized because they are generally hardcoded in English by the entities providing the error messages. In this case, your application should be updated to display custom error messages to your users instead of raw messages.
• Identifying EVERY source of user-facing text: There are many possible sources of text in your application that can go unnoticed, which can then become difficult to handle late in the localization process. Some examples are images, email templates, and messages from external libraries/packages/APIs. If you are doing frontend only localization, then it becomes necessary to make 100% certain that there is NO user facing text coming from the backend – if you discover late in the process that some user facing text comes from the server, then some “hacky” solutions may be necessary to preserve the frontend-only localization scheme.
• Not enforcing a single source of truth for text: If there is not a very solid system in place for establishing and updating the “source or truth” for translated text, then the localization process can quickly become messy. Things are always changing during development, and if there is not an established system to deliver text updates to translators and other stakeholders, then any one party can modify text without other stakeholders’ knowledge and introduce confusion. Enforce a single source of truth for text that all stakeholders can agree on. (Resource files are likely NOT the appropriate single source of truth, since non-developer stakeholders should also have control over text in the application.)

The post Basic JavaScript Localization Setup Using JSON with Visual Studio Code appeared first on DMC, Inc..

During one of the project stages, for various reasons, I was not able to deploy additional logging to see the parameters that were being retrieved from a database. You might think that I could’ve simply run the code locally and seen the results there, but locally I had no access to the database due to the client’s firewall configurations.

The only plausible solution was to attach the debugger to the code that was running on the cloud. Seemingly, there are two main solutions in the 2022 Visual Studio, and it took me a little longer than I wish it did to connect to a remote process. To save you some time, I have summarized the steps I took while trying to review possible edge cases that might help you with troubleshooting.

I put this guide together for both solution options, but I do have to warn you that even though the Publisher seems like a better, faster, and easier option, it did not work for my case, and I had to resort to the more manual option (which I, personally, prefer anyway).

Both options must enable remote debugging.

Firstly, you will navigate to the “General settings” subpage of the “Configuration” tab of your Function App and enable remote debugging. Enabling this setting allows you to connect a remote debugger to the code running on the cloud.

Option 1 – “Attach to Process” in the Debug drop-down menu.

1. For option one, you will navigate to Visual Studio and select “Attach to Process” under the “Debug” option of the top bar menu panel. This item has a handy shortcut: Ctrl+Alt+P.

• Microsoft documentation on “Attach to running processes with the Visual Studio debugger”

Image 2. Select “Attach to Process” in the drop-down menu or use a Ctrl+Alt+P shortcut.

2. You will have to provide the connection target, which you can find in the “Overview” of your Function App. The target is the URL to your Function Application with an appropriate Visual Studio port. Don’t forget to omit the https:// part of the URL.

Image 3. Copy the target URL from the Function App Overview page.

3. Visual Studio port is determined by its version (taken out of official Microsoft documentation as of January 2023):

Note: I could not attach to a process using port 4026 because remote debugger ports on Microsoft Azure App Services are configurable, and they do not use the default ports associated with your version of Visual Studio. They use port 4024 for the remote debugger.

• Microsoft documentation on “Remote Debugger Port Assignments”

Image 4. Use the target URL with an appropriate Visual Studio port.

4. Without clicking anything, press Enter after you are done inputting the connection target. This will prompt a window for your credentials. This part is a little misleading because, in my case, the authentication window automatically prompted me to give my laptop credentials, but those are not the ones you want to put in here. Instead, select the “More choices” option and then hit “Use a different account.” This will prompt for a username and a password — which you can find in Azure. Disregard the “Domain” part of the window as it will get populated automatically if you use the correct username.

Images 5, 6, 7. (Left to right, top to bottom) These are steps 1, 2, and 3 in navigating to a window where you provide credentials to connect to your application.

5. The credentials you are going to use to connect to remote processes can be found in the “Deployment Center” of your Function App. Navigate to the “FTPS credentials” subpage and copy the username and password exactly into the window that prompted you for credentials. You can also add user scope, but I did not see the necessity for it for my case.

Image 8. Find credentials in the deployment center of your application.

Image 9. Use the credentials to attach the debugger to your target.

6. If the connection successfully establishes, you will see various processes that you may be able to attach to. Since my application is an Azure Function App, I was only able to attach to dotnet.exe – .NET Core Host. I have seen online that, to attach the debugger to a Web App, you might have to use the w3wp.exe – IIS Worker Process. 

Image 10. This is a view of processes to attach to.

7. Once attached, you should be able to successfully set a breakpoint in your code. Since the app runs on cloud, there is a slight latency, and it might take a little longer for the code to hit the breakpoint or for you to set it — but it is almost negligible. If the breakpoint doesn’t get set or if you encounter other issues along the way, check out this blog I used when troubleshooting.

Option 2 – Visual Studio Publisher

1. If you have used the Publisher before, you might not even need this guide, that’s how straightforward this method is. If not, let’s look at how you can use the new features of Visual Studio to your advantage.
Firstly, you will have to create a Publishing Profile. Right-click your function app in Visual Studio and select “Publish” option. This will prompt you to set up a Publishing Profile.

Image 11. These are options for your Function App.

2. Since we are trying to attach the debugger to a Function App on Azure, we will select the Azure option.

Image 12. These are publishing options.

3. By default, my example runs on a Windows Azure Function App, and that is the option I selected.

Image 13. These are Azure services options.

4. The next step is to select which Function App you want to connect to. I can’t really help much here because you will need to choose which app, service, and resource you are attaching based on your environment setup.

Image 14. Select the Azure Function App for which you are creating this Publisher.

5. You can hit “Finish” because the next window is optional. It asks if you want a pubxml or a yml file and, for the purpose of this guide, you should select the default pubxml.

Image 15. These are Publisher format options.

6. Once you click “Finish,” this will automatically create the Publisher Profile for you. Successful creation will show an appropriate message.

Image 16. This displays the successful creation of a Publisher Profile.

7. Now you should simply be able to navigate to the options of the Profile and select “Attach Debugger.” Make sure you publish the application in Release mode using this Publisher before attaching the debugger. This is all you need to do if you are using the Publisher. This did not work for me because the default process that the Publisher attaches to was not the Function App that I needed to debug. It was w3wp.exe – IIS Worker Process instead of dotnet.exe – .NET Core Host by default.

Image 17. This is a Publisher interface to attach the debugger.

Important troubleshooting notes:

1. Your code must be up to date with the current version on the cloud. Even though I had the latest version of the code, I had to redeploy to attach the debugger. This especially applies to the Publisher Profile.
2. When attaching to process, you might have to manually figure out where to attach. As I was debugging a .NET Azure Function Application, I had to attach to the dotnet.exe process, but I have seen tutorials where you had to attach to w3wp.exe for certain web applications.
3. The credentials are not your laptop nor your account credentials. They are the FTPS credentials from the Deployment Center of your application.
4. It seems that the Publisher option configures everything for you. The feature seems nice, but it did not work for my case. I had to specifically attach to the dotnet.exe process because all other processes would not load any symbols, and the Publisher had the same issue for me. It wouldn’t load the symbols, so I could not really set any breakpoints and debug the code. I imagine that it connects to w3wp.exe by default as I have seen in other tutorials.
5. Another quite crucial note is that, when you attach to process, you only attach to one process. That is, if your application is multi-threaded, then you will only attach to one thread. I learned it the hard way. Every time I attached to a process and sent a request, the breakpoint would not always get hit, and sometimes I would receive requests that I have never sent. If you do decide to proceed with this debugging technique, be prepared to rely on chance and make sure that no one else is utilizing the application because they will see some weird behavior of their processes getting stuck on your breakpoint.
6. I have seen situations where people had to disable the “Just My Code” option to make this work, but I never saw the necessity in that. I have it turned off by default, but having it on should not cause any issues; however, you can try it if nothing else is working in your troubleshooting endeavors.
   1. Microsoft documentation on “Just My Code”
7. If you are using a Publisher, make sure to deploy the code under the Release mode.

Learn more about DMC’s Microsoft Azure Cloud Solutions and Services and contact us today for your next project.

The post Remote Attach Debugger to Process in the Cloud appeared first on DMC, Inc..