How to Limit Nuxt Page Translations to Specific Locales Using defineI18nRoute()

If you’re working with multilingual Nuxt 3 applications and using @nuxtjs/i18n, you may run into a scenario where only specific pages should be available in certain locales (e.g., /en-ae/menu, /ar-sa/menu) while others like /fr/menu should be disabled. Here’s how to do exactly that — the right way.

✅ Packages Used

  • nuxt@^3.17.2
  • @nuxtjs/i18n@^10.0.0-beta.4

✅ Problem Statement

You want a page like /menu to be available only in specific locales — such as:

  • /en-ae/menu
  • /en-sa/menu
  • /ar-sa/menu

And disable it for all others like /fr/menu or /ar-ae/menu.

✅ The Right Way: defineI18nRoute()

Nuxt i18n provides a way to control routing per-page. You can use the defineI18nRoute() composable inside the page component to control which locales should have this route.

pages/menu.vue

<script setup lang="ts">
defineI18nRoute({
  locales: ['en-ae', 'en-sa', 'ar-sa']
})
</script>

<template>
  <main>
    <div class="text-center py-20">
      <h1>{{ $t("global.menu") }} - {{ $t("global.app_name") }}</h1>
    </div>
  </main>
</template>

🔧 Required Configuration in nuxt.config.ts

export default defineNuxtConfig({
  i18n: {
    strategy: 'prefix',
    customRoutes: 'config', // Required to use defineI18nRoute
    defaultLocale: 'en-ae',
    locales: [
      { code: 'en-ae', file: 'en-ae.json' },
      { code: 'en-sa', file: 'en-sa.json' },
      { code: 'ar-sa', file: 'ar-sa.json' },
      { code: 'ar-ae', file: 'ar-ae.json' },
      { code: 'fr', file: 'fr.json' }
    ]
  }
})

🧠 What Doesn’t Work

  • definePageMeta({ nuxtI18n: false }) disables localization entirely — not selectively.
  • There’s no excludeLocales or blacklist feature — only locales: [...] whitelist via defineI18nRoute.

✅ Final Notes

This method gives you per-page control over what locales are allowed — ideal for region-specific or language-limited content in Nuxt projects.

Want to automate locale inclusion/exclusion across many routes? Stay tuned for a follow-up post on dynamically managing i18n page access in Nuxt.

Detect Undefined Properties in Vue Templates with ESLint (vue/no-undef-properties)

Why ESLint Should Catch Undefined Properties in Vue

Undefined property references in Vue templates often go unnoticed until runtime. While IDEs like VSCode can detect these issues with TypeScript, they don’t enforce them in your CI/CD pipeline. To guarantee full static analysis coverage, you need ESLint to catch these template errors.

Example Problem

A simple Vue component might contain this:

<template>
  <button @click="loadForm()">Load Form</button>
</template>

<script lang="ts">
export default {
  // loadForm is referenced but never defined
};
</script>

Your IDE may show a type error, but ESLint won’t unless configured properly.

Step 1: Install the ESLint Vue Plugin

The required rule is part of the eslint-plugin-vue package. Install it using:

npm install --save-dev eslint-plugin-vue

Step 2: Add the Rule to Your ESLint Configuration

Edit your .eslintrc.js file and include the following:

module.exports = {
  root: true,
  extends: [
    "plugin:vue/vue3-essential",
    "@vue/eslint-config-typescript/recommended",
    "@vue/eslint-config-prettier"
  ],
  rules: {
    "vue/no-undef-properties": "error"
  }
};

This ensures that any reference to a non-existent method or data property in your template is flagged as an error.

Optional: Add Related Rules

For broader template validation, consider adding:

"vue/no-unused-properties": "warn",
"vue/no-undef-components": "warn"
  • vue/no-unused-properties: Detects component properties that are defined but unused.
  • vue/no-undef-components: Detects unregistered components used in templates.

Conclusion

Enabling vue/no-undef-properties in ESLint brings strict, template-aware validation to your Vue development workflow. It prevents silent failures and improves reliability across the codebase—especially when used in automated checks.

Using Multiple GitLab SSH Keys for Different Accounts or Projects

Managing multiple GitLab accounts or using different SSH keys for different projects can be tricky, especially when you need Git and SSH to automatically use the correct identity. Here’s a clean and reliable way to configure it.

Problem

When working with multiple GitLab repositories tied to different accounts or SSH keys, Git may use the wrong identity, leading to errors like:

ERROR: The project you were looking for could not be found or you don't have permission to view it.

Solution Overview

We solve this using:

  1. SSH Config Aliases – to map keys to specific hostnames.
  2. Git URL Rewriting – to route Git URLs through the right SSH alias automatically.

Step 1: Define SSH Config

Edit or create ~/.ssh/config:

Host gitlab.com-user1
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_user1
  IdentitiesOnly yes

Host gitlab.com-user2
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_user2
  IdentitiesOnly yes

Each Host entry points to a unique key for a specific GitLab account.

Step 2: Configure Git URL Rewriting

Set Git to rewrite the standard GitLab URLs to your aliases.

git config --global url."git@gitlab.com-user1:user1/".insteadOf "git@gitlab.com:user1/"
git config --global url."git@gitlab.com-user2:user2/".insteadOf "git@gitlab.com:user2/"

This way, even if you clone using the standard URL, Git will internally reroute it.

If you’ve added a less-specific rule before (e.g., missing the namespace), remove it:

git config --global --unset url."git@gitlab.com-user1:".insteadOf
git config --global --unset url."git@gitlab.com-user2:".insteadOf

Step 3: Use Standard GitLab URLs

You can now clone or use remotes like:

git@gitlab.com:user1/repo-name.git
git@gitlab.com:user2/another-repo.git

Git will rewrite them automatically based on your rules, and SSH will use the correct key.

Step 4: Verify It Works

To confirm Git is using the correct SSH key:

GIT_SSH_COMMAND="ssh -v" git ls-remote origin

Look for a line like:

Offering public key: /home/youruser/.ssh/id_ed25519_user1

This confirms the correct key is being used.

Conclusion

With SSH config aliases and Git URL rewriting, you can work with multiple GitLab accounts or SSH keys seamlessly, without changing URLs manually or running into permission errors.

This setup is flexible, clean, and scales well across teams or machines.

How to Serve Apple Pay Domain Association File Using NGINX and Nuxt 3

Steps to Serve the Apple Pay Domain Association File Using NGINX and Nuxt 3

1. Proxy the File to the Nuxt Dev Server

Since the Nuxt 3 development server is already serving the file correctly on localhost:3000, we can configure NGINX to proxy just this specific request to the dev server.

Here’s how you can do it:

NGINX Configuration:

In your NGINX configuration file, add the following block to proxy requests for the Apple Pay domain association file:

location = /.well-known/apple-developer-merchantid-domain-association.txt {
    proxy_pass http://localhost:3000/.well-known/apple-developer-merchantid-domain-association.txt;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

This configuration ensures that when a request is made to access the Apple Pay domain association file, NGINX will proxy that specific request to the Nuxt dev server, where the file is already correctly served.

2. Reload NGINX

After making changes to the NGINX configuration file, you will need to reload NGINX for the changes to take effect. Use the following command to reload NGINX:

sudo systemctl reload nginx

This will restart the NGINX server and apply your new configuration without any downtime.

3. Access the File via Your Domain

Once your NGINX configuration is updated and reloaded, you can verify that the file is being served correctly by navigating to:

https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association.txt

With just a few lines added to your NGINX configuration, you can easily serve the apple-developer-merchantid-domain-association.txt file during the Apple Pay domain verification process. This method works seamlessly with a Nuxt 3 development server, keeping your setup simple and efficient. However, don’t forget to adjust the configuration for production environments when necessary.

By following this guide, you’ll be able to quickly verify your domain for Apple Pay, ensuring that you can securely process payments on your Nuxt-powered site.

Efficient Solution for Vuelidate Nested Validations: Overcoming Maximum Recursive Updates in Vue.js

To resolve the ‘Maximum recursive updates exceeded’ error in Vue.js, often caused by complex nested validations, the implemented solution involves dividing the validation logic across two distinct components. By avoiding deep nesting, this method simplifies the validation process. Each component (‘First.vue’ and ‘Second.vue’) independently handles its segment of the validation logic using Vuelidate. This separation ensures more manageable and modular code, significantly reducing the risk of triggering recursive update errors that are common in tightly nested validation structures. This approach not only enhances code readability and maintainability but also improves performance by preventing the excessive recursive calls that can occur in deeply nested validation scenarios.

Solving Vue 3 Axios CSRF Token Mismatch with Laravel API

While working with Vue 3 and Laravel APIs, a common issue you might encounter is the “CSRF Token Mismatch” error. This problem arises when Axios, a popular HTTP client for making requests, fails to send the necessary X-XSRF-TOKEN in the request header. This article explains how to resolve this issue by intercepting requests and adding the required token.

Understanding the Problem

The Cross-Site Request Forgery (CSRF) Token Mismatch error typically occurs when a request is made from a local domain to a Laravel API. Laravel expects a CSRF token as a part of the request for security purposes. However, when Axios does not include this token in the header, Laravel rejects the request, leading to an error.

The Solution: Intercepting Requests with Axios

The solution lies in modifying the request before it’s sent. By using Axios’ request interceptors, you can ensure that the X-XSRF-TOKEN is included in every request header. Below is a step-by-step guide on how to implement this.

1. Setting Up Axios Instance

First, create an Axios instance with the necessary configurations:

import axios from 'axios';
import Cookies from 'js-cookie';

const httpApi = axios.create({
  baseURL: process.env.VUE_APP_API_URL,
  withCredentials: true,
  headers: {
    "X-Requested-With": "XMLHttpRequest",
  },
});

Here, withCredentials: true is crucial for sending cookies in cross-origin requests.

2. Adding a Request Interceptor

Next, add a request interceptor to Axios:

httpApi.interceptors.request.use(function (config) {
  const token = Cookies.get('XSRF-TOKEN');
  if (token) {
    config.headers['X-XSRF-TOKEN'] = token;
  }
  return config;
}, function (error) {
  return Promise.reject(error);
});

This interceptor function runs before each request is sent. It retrieves the CSRF token from the cookies using js-cookie and adds it to the request headers.

3. Exporting the Configured Axios Instance

Finally, export the configured Axios instance for use in your Vue components:

export { httpApi };

Conclusion

By intercepting requests and adding the X-XSRF-TOKEN header, you can smoothly integrate Vue 3 with a Laravel API without encountering CSRF Token Mismatch errors. This approach enhances the security of your application while ensuring seamless communication between the client and server.

VS Code Path Intellisense config for JavaScript

Edit/Add jsconfig.json

{
    "compilerOptions": {
      "baseUrl": ".",
      "paths": {
        "@/*": ["src/*"]
      }
    },
    "exclude": ["node_modules", "dist"],
    "include": ["src/**/*.vue", "src/**/*.js"]
  }

Edit VS Code settings.json and add

 "typescript.suggest.paths": false,
 "javascript.suggest.paths": false

How to enable nginx stub status

How to enable nginx stub status

Edit nginx.conf add in the server { ….. } block/context

location /nginx_status {
	# Turn on nginx stats
	stub_status on;

	# I do not need logs for stats
	access_log   off;

	# Security: Only allow access from your IP address #
	allow your ip address;

	# Send rest of the world to /dev/null #
	deny all;
}

For Plesk edit  /etc/nginx/plesk.conf.d/server.conf

Could not open archive dir for / Could not open archive mbox dir

/usr/local/cpanel/scripts/update_mailman_cache

How to fix the errors

Could not open archive mbox dir for somelist: No such file or directory at /usr/local/cpanel/Cpanel/Mailman/DiskUsage.pm
Could not open archive dir for somelist: No such file or directory at /usr/local/cpanel/Cpanel/Mailman/DiskUsage.pm

Solution

If we have a list named list1_webinformat.com the error is

Could not open archive mbox dir for list1_webinformat.com: No such file or directory at /usr/local/cpanel/Cpanel/Mailman/DiskUsage.pm

and we have to create 2 dirs

mkdir /usr/local/cpanel/3rdparty/mailman/archives/private/list1_webinformat.com.mbox
mkdir /usr/local/cpanel/3rdparty/mailman/archives/private/list1_webinformat.com

After we create the needed directories we run 2 commands

/usr/local/cpanel/scripts/fixmailman

/scripts/update_mailman_cache

Let me know in comments if you need any help or if this helped you.
Happy coding 😉