Vanity Path Issue in Hindi Pages: %20 (Space Encoding) Added Automatically

[NandheswaraS_]

Hi Everyone,

We are facing an issue in our AEM setup related to vanity paths and Hindi pages.

Problem Statement

• When we author a page content path in Hindi pages, a %20 (encoded space) is getting appended at the end of the vanity path.

• This behavior is observed only for Hindi pages.

• For English pages, sling:vanityPath property, and we directly use the same vanity path without issues.

Observations

1. The issue happens only after translation (we usually author English pages and then translate them to Hindi using Process9).

2. In Author mode, when the content path is authored, it looks fine. But once published, the vanity path automatically adds %20 at the end.

   • Example: /hindi/page → becomes /hindi/page%20.

3. For English pages, vanity paths remain clean and this issue does not occur.

4. There is no visible trailing space in the sling:vanityPath Property.

What We Tried

• Checked page properties and vanity path values — in English they are clean.

• Verified that no explicit sling:vanityPath property is set in English pages.

• Replication to Publisher always adds %20 if a trailing space exists in the path.

Can you provide the suggestion to resolve this issue.

Regards,

Nandheswara S M

[HrishikeshKagne]

Hi @NandheswaraS_ ,

This happens because the Hindi translation is adding a hidden trailing space in the sling:vanityPath value. When published, AEM encodes that space as %20.

• Open the vanity path property in CRX/DE or use a script to trim trailing spaces.

• Enforce validation/normalization (e.g., custom workflow step or listener) to strip spaces when vanity paths are created by translation.

remove the hidden trailing space in the vanity path; add a trim step so translation doesn’t introduce it again.

[SantoshSai]

Hi @NandheswaraS_,

Your Hindi pages’ sling:vanityPath values have a trailing whitespace character (often invisible: space, NBSP \u00A0, ZWNBSP \uFEFF, ZWSP \u200B). On publish, that gets URL-encoded - %20 at the end. Translation (Process9) or copy/paste usually introduces it. The Page Properties UI can hide it, so it “looks fine” in Author.

Please confirm it

• Open the page’s jcr:content.json and inspect the raw sling:vanityPath string(s) - you’ll see the extra char at the end.

• Also check if the property is multi-valued and accidentally contains both "/hindi/page" and "/hindi/page ".

See below to fix existing content (one-time clean)

• Run a small trim job on Author (egACS Groovy Console), then re-publish + flush:

def base = "/content/your-site/hi"
resourceResolver.getResource(base)?.adaptTo(org.apache.sling.api.resource.Resource.class)
def changed = 0
resourceResolver.findResources("SELECT * FROM [nt:base] AS n WHERE ISDESCENDANTNODE(n, '${base}')", "JCR-SQL2").each { r ->
  def node = r.adaptTo(javax.jcr.Node)
  if (node?.hasProperty("sling:vanityPath")) {
    def vals = node.getProperty("sling:vanityPath").isMultiple() ?
      node.getProperty("sling:vanityPath").getValues().collect{ it.string } :
      [node.getProperty("sling:vanityPath").getString()]
    def cleaned = vals.collect{ it?.replaceAll(/[\\s\\u00A0\\u200B\\uFEFF]+$/,"") }.unique()
    if (cleaned != vals) {
      if (cleaned.size() > 1) node.setProperty("sling:vanityPath", cleaned as String[])
      else node.setProperty("sling:vanityPath", cleaned[0])
      changed++
    }
  }
}
session.save()
"Updated vanityPath on ${changed} node(s)"

and please consider below points to prevent it going forward

• Add a post-translation normalizer (workflow step/listener) to trim() vanity paths before activation.

• If authors set vanity in Page Properties, add a tiny client-side validation (or server-side filter) to strip trailing whitespace and dedupe values.