[Feature Request] i18n support #20

Activity

1. Deku-nattsu

   added

   bugSomething isn't workingSomething isn't working

   on Jan 27, 2026
2. edwardloopez commented on Jan 30, 2026

   

   edwardloopez

   on Jan 30, 2026

   Last edited by edwardloopez

   Owner

   More actions

   Heyyy! Thanks so much for opening this issue and for the kind words about the package!!

   You're absolutely right - the hardcoded labels are a real limitation for non-English apps. I really appreciate you taking the time to explore solutions with a local clone and thinking through the API design.

   Both of your proposals make sense, but I'd like to suggest a third option that combines the best of both approaches and adds more flexibility:

   interface I18nLabels {
     next: string | ((step: number, total: number) => string);
     back: string | ((step: number, total: number) => string);
     skip: string;
     done: string;
     stepAnnouncement?: (step: number, total: number, title?: string, description?: string) => string;
     nextHint?: string;
     backHint?: string;
     skipHint?: string;
     doneHint?: string;
   }
   
   // Usage in CoachmarkProvider
   <CoachmarkProvider 
     labels={{
       next: (step, total) => t('coachmark.next', { step, total }),
       back: (step, total) => t('coachmark.back', { step, total }),
       skip: t('coachmark.skip'),
       done: t('coachmark.done'),
     }}
   >

   Why this approach:

   • Supports both simple strings and functions for dynamic content
   • Provides sensible defaults (current English labels) for backward compatibility
   • Extensible - we can add more labels in the future without breaking changes
   • Also allows customizing accessibility hints
   • Keeps the library lean - consumers handle their own i18n solution

   What do you think? Would this work for your use case? I'm totally open to adjusting this based on your feedback since you've already been experimenting with the code.

   And yeah, sorry about not having discussions enabled - thank you for saying this. I already turned that on! Feel free to open the discussion so we can continue from there.

   NOTE This would apply to the default Tooltip component. If you're using custom tooltips (via the renderTooltip prop), you'd handle i18n however you want in your custom component - which gives you complete control when you need it.
3. edwardloopez

   self-assigned this

   on Jan 30, 2026
4. Deku-nattsu commented on Jan 31, 2026

   

   Deku-nattsu

   on Jan 31, 2026

   Author

   More actions

   @edwardloopez LGTM! that would do it.

   Honestly i didn't try passing my own tooltip component and was considering the fast approach of consuming this library.
5. edwardloopez commented on Jan 31, 2026

   

   edwardloopez

   on Jan 31, 2026

   Owner

   More actions

   @Deku-nattsu I completely agree with you. This would be very useful for people who want to quickly make use of the library!

   👍React with 👍1Reacted by Ayman Bousselham
6. Repository owner locked and limited conversation to collaborators on Jun 18, 2026
7. edwardloopez

   converted this issue into a discussion #32 on Jun 18, 2026