Slice Machine does not support Cyrillic slice names — model and screenshot files end up in root slices folder

Developing with Prismic
1

Hello!

I want to use slice names in Cyrillic (Russian) for my project. However, Prismic Slice Machine does not allow me to enter Cyrillic characters when creating a new slice — it only accepts Latin characters for the slice name/API ID.

To work around this, I manually set the display name in Cyrillic in the model.json file of each slice (for example, "name": "Контакты"). The folder and API ID remain in Latin (e.g., Contacts).

The problem is:

Whenever I make changes to a slice using Slice Machine (for example, editing the model or updating the screenshot), the updated model.json and screenshot.png files are saved in the root slices folder, not in the specific slice’s folder. This causes issues with slice previews and organization.

How can I use Cyrillic display names for slices and still have Slice Machine save the model and screenshot files in the correct slice folder?

Is there a recommended way to support non-Latin display names for slices?

Thank you!

2

Hello @vagmen27,

Thanks for raising this! We don't currently support non-latin letters/alphabets in the Slice Machine. I completely see your use case for this, so I'm going to make a feature request and bring it to the team. I can't promise they'll get to it immediately, but they take user feedback very seriously and will have a look at it. I've linked this forum post to it, so whenever we have news, we can keep you updated :slight_smile:

Regarding the way you've been working around this, it works in the model.json because you're doing it manually, but I'm afraid since we don't support it, there's not going to be a way for it to seamlessly work the way it should. If it works to manually move them back, you can continue doing this for the time being, but it must not recognize and link the modified name with non-supported letters.

I hope this helps!

3

Hello team,

Thank you for logging the feature request to support non-Latin characters in Slice Machine.
After digging deeper, I’d like to outline what would be the ideal fix, offer a fallback that keeps full backward compatibility, and explain why the issue is important for a growing number of users.

1. Ideal solution

Keep id as the immutable ASCII identifier; let name be truly human-readable (full Unicode).

{
  "id": "process_steps",       // ASCII, matches folder/API, never shown to editors
  "name": "Этапы процесса",     // Unicode, shown in the UI, stored in slice JSON
  "type": "SharedSlice",
  "description": "timeline / numbered / icon-cards",
  "variations": [ … ]
}

id continues to drive file paths, slice-type look-ups, screenshots, etc.
name becomes the single source of truth for what editors see — exactly how Custom Types already work today.

2. Fallback (zero-risk) solution

If changing the semantics of name is risky, add an optional label field (Unicode) while keeping id and name untouched:

{
  "id": "process_steps",
  "name": "ProcessSteps",      // stays ASCII for full backwards compatibility
  "label": "Этапы процесса",    // NEW: shown in UI only
  …
}

This mirrors the existing id + label pattern used in Custom Types and can be introduced without any migrations.

3. Why it matters

Pain point Impact
Editor friction Content teams working in Russian, Ukrainian, Bulgarian and other Cyrillic-based languages stumble over transliterated names like “ProcessSteps” or “Kontakty”. Native labels eliminate confusion and shorten onboarding.
Inconsistent UX Custom Types already accept Cyrillic names; Shared Slices do not. This inconsistency forces us to hack description or to move files by hand when Slice Machine writes to ./slices root.
Market reach Agencies in Eastern Europe, the Middle East and Asia weigh localisation quality heavily when choosing a CMS. Proper Unicode labels would make Slice Machine instantly more attractive to thousands of potential users.
Cleaner repos A first-class field removes the need for watcher scripts that move misplaced model.json and screenshot.png back into the correct slice folder.

Even the fallback option (#2) would solve 100 % of the editor-side pain without touching existing projects.
If the team can safely implement the ideal approach (#1), it would keep the JSON even simpler and closer to how Custom Types behave.

Thanks again for listening to your community. Please let me know if any additional information would help when prioritising this request.

Best regards,
Vagiz

1 Like