[Feature Request] i18n support

[Deku-nattsu]

Before submitting a new issue

• I tested using the latest version of the library, as the bug might be already fixed.
• I tested using a supported version of react native.
• I checked for possible duplicate issues, with possible answers.

Bug summary

Before anything thanks for the awesome package!

Since discussions aren't enabled in this project i am creating an issue for this feature request

Right now the buttons labels of this package are hardcoded with no possible ways of customizing it this limits the reach of this great package in non english react native apps.

I am playing with a local clone of the package and trying come up and an API design that the community would agree on. My general idea is letting the consumer handle the translations rather than bloating this package with it and so far i came up with two options:

The first option:

Adding getButtonLabel to the props CoachmarkProvider and providing it with the context to use for the internal components such as ToolTip.

The second option:

Instead of passing a function we pass an object that will expose the actions

accessibilityLabels: {
    next: (nextStep, total) => t('coachmark.next', { nextStep, total }) // i18next example,
  }

I could take care of integrating this once we agree on something 😁

Library version

0.5.1

Environment info

noop

Steps to reproduce

noop

Reproducible example repository

noop

[edwardloopez]

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.

[Deku-nattsu]

@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.

[edwardloopez]

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