Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Status

Status
colourGreen
titleDECIDED

Owner

Eric TRIFFAUX

Stakeholders

Avanade, TDA


Info

Decision:

  • Site Name
    • Option A (English translation using SyGPT to keep the meaning and with limitation to 30 characters)
    • to be avoided : Option B (transliteration)
    • Migration-only fallback: Option C (Prefix + drive ID)
    • Adopt proposed naming convention for new site
    • Adopt proposed naming convention for migrated content
  • URL :
    • Option 1 : URL reflects name (normalized version via SyGPT)

Decision made by: Infra TDA

Date: 

Online Meeting: TDA

Decision Context

As part of adopting SharePoint Online, two urgent needs arise:

...

  • Information architecture

  • Governance

  • Migration effort

  • Multilingual support

  • Automations & provisioning

  • User experience

  • Integration with Teams & OneDrive

  • Path-length stability (400‑char URL rule)

  • Long-term platform scalability

Problem Statement

SharePoint Online URLs do not support non‑ASCII characters, such as:

...

  • Whether site names should match URLs
  • How to standardize URLs when names include unsupported characters
  • Whether to translate names to English, transliterate, or use external system IDs

Architectural Requirements

URL technical constraints (SharePoint Online)

...

  • Users must easily recognize:

    • The purpose of the site

    • Ownership (INT/EXT)

    • Department

    • Team

    • Region or geography

  • Site URLs should remain clean, short, predictable

SharePoint Naming convention

Golden rules

  • External and internal are optional, and to be used if explicitly limited to Internal or external content.

  • Avoid special characters : # % & * { } \ : < > ? / + | "

  • No accents, diacritics, or non ASCII characters : Proposal is to use SyGPT to translate into english tokeep the meaning and keep it short

  • Names must be short <30 caracters

  • Human friendly names : Use PascalCase or Title Case for Site Names (but not URLs)

  • When possible avoid space

  • Avoid stacking long department or project names.

  • Use 3–5 meaningful elements maximum.

  • Depending the SharePoint structure, it will not be required to use all elements in the name likeDepartment, domain, team; while using HUB site this can reflect the organization and ease thenavigation.

  • HUB Site will be created explicitly, if a site is promoted it will be renamed.

  • DATE will use ISO format (YYYYMMDD)

New Sites

* Ext and int removed. Only EXT if the site is completely for external vendor or party
*1 : better to create dedicated hub

Workspace Type

Best Use Case

Name

Teams Team

Daily collaboration + chat + files

TEAM-[INT/EXT]-[Dept]-[Team]-[Region]

Teams Standard Channel

Organizing work by topics

[TopicName]

Teams Private Channel

Sensitive sub-team collaboration

PRIV-[Team]-[TopicName]

SP Team Site (Group)

Document collaboration without Teams

SITE-[Dept]-[Team]-[Region]

SP Team Site (No Group)

Highly controlled teams, external collab

SITE-[Dept]-[Purpose]-[Region]

Communication Site

HR/IT/Finance portals

COM-[Domain]-[Region]

Hub Site

Organizing the intranet

HUB-[Dep/Domain/Function] *1

Project/PWA Site

Formal project management

PROJ-[ProjectName]-[YYYY]

Wiki / KB

SOPs, knowledge articles

KB-[Topic]
WIKI-[Dep/Domain/Function]

Home Site

Main corporate intranet homepage

HOME

External Sharing Site

Supplier, customer, partner workspaces

SITE-EXT-[Dept]-[Partner]

Archive Site

Preservation of closed projects or teams

ARCH-[Dept/Project]-[YYYY]

Migrated content

 Follows the standard naming convention when possible with adjustments

...

Type

Convention

AODOcs

AO_

SharedDrive

SHD_

Gsites

GS_

Application Sharepoints

APP-

URLs

URL will benefits naming convention

...

  • In case of library name, folder, file too long , possibility to contact theowner with a proposed renaming from SyGPT to translate into english tokeep the meaning and keep it short
  • If not possible we revert to Google IDs

Recommended Decision

  • Site Name 

    • Option A (English translation using SyGPT to keep the meaning and with limitation to 30 characters)

    • to be avoided : Option B (transliteration)

    • Migration-only fallback: Option C (Prefix + drive ID)

    • Adopt proposed naming convention for new site

    • Adopt proposed naming convention for migrated content

  • URL :

    • Option 1 : URL reflects name (normalized version via SyGPT)

Options Considered

New Sites

Option A: Reflect the site name in the URL using English translations.

Option B: Where translation is not appropriate use Transliteration

Option C: Migration Strategy (Legacy Shared Drives / AODocs only)

  • Clean syntax
  • Short and consistent
  • Easy to govern
  • Fully compliant with Microsoft’s URL restrictions
  • Enhances user experience, searchability, and automation
Use transliteration to convert unsupported characters into ASCII equivalents.

For migrated content, add the prefix (SHD_ or AOD_) and optionally if Option A not applicable → append the Google Shared Drive ID when the name is ambiguous or unsafe.

Example:
SHD_Finance-A1B2C3D4


Should the Name Be Reflected in the URL?

Option 1 — YES: URL reflects name (normalized version – recommended)

Option 2 — NO: URL uses a generated technical ID

Example:
Site Name: Finance – Contrôle de Gestion
URL: /sites/FIN-Controlling

✔ Advantages

  • Improves findability (people can guess URLs)
  • Consistent with Microsoft 365 naming governance
  • Works well with automation & provisioning
  • Easier audit & support
  • Matches industry best practices
  • Helps avoid orphan or duplicated sites
  • Short, stable naming helps avoid the 400‑char limit

✘ Drawbacks

  • Names must be translated or transliterated
  • Some business units may resist non-native naming
  • Requires an authoritative naming dictionary

Example:
Site Name: Finance – Contrôle de Gestion
URL: /sites/123abcXYZ

✔ Advantages

  • Fully avoids unsupported characters
  • Guaranteed uniqueness
  • Stable even if site name changes

✘ Drawbacks

  • Impossible for users to guess what a URL is
  • Poor user experience
  • Not suitable for enterprise intranet architecture
  • Makes governance and audits harder
  • Not aligned with M365 best practices

How Should We Handle Unsupported Languages?

(Below are the clear options for dealing with non‑ASCII names in URLs.)

Option A — Translate the name to English (using SyGPT for consistency)

Option B — Transliterate the name (convert characters to ASCII)

Option C — Use the Google Shared Drive ID as URL suffix

Example: “Équipe de Gestion” → “ManagementTeam”

✔ Pros

  • Aligns with international corporate standards
  • Guarantees URL compatibility
  • Clean, short URLs
  • Matches most global enterprises’ practices
  • Only requires one corporate dictionary (SyGPT can generate it)

✘ Cons

  • Teams in non‑English regions may feel less represented
  • Requires validation of translations

Example: “Société Générale” → “SocieteGenerale”

✔ Pros

  • Preserves local identity
  • Predictable and intuitive result
  • No need to translate terms
  • Works well with automated rules

✘ Cons

  • Some languages (Arabic, Chinese) transliterate poorly
  • Still requires a dictionary for consistency
  • Risk of ambiguous results

Example: Shared Drive ID = A1B2C3D4/sites/FIN-A1B2C3D4

✔ Pros

  • Perfectly unique
  • Great traceability from migration source
  • No naming conflicts
  • No translation needed

✘ Cons

  • Very poor readability
  • URL becomes meaningless for users
  • Not scalable for future (non-migration) sites
  • Only relevant for migrated content
  • Inconsistent with new SharePoint sites created post‑migration

6. Evaluation Matrix

CriteriaOption A: English Translation ✅Option B: TransliterationOption C: Google Drive ID☑️
User-friendly URLs
Technical compatibility
Works for future sites
Predictability
Readability
Consistency across organization⚠️ depends on language
Migration suitability
Long-term governance fit

See also

The following section describes relevant documentation:

...