Kiswahili language support

[c12i]

Summaries are currently stored in English. Since the goal of this project is to make legislative information accessible to all Kenyans, providing Kiswahili translations alongside the original is essential.

[ayimdomnic]

@c12i I'd love to take this on.

Before diving in, I have a few clarifying questions:

1. Which parts of the UI should be prioritized for Kiswahili support? (e.g., nav, buttons, streamed content?)
2. Is there a preferred i18n library or strategy already in place (e.g., remix-i18next)?
3. Should translations be statically embedded in the frontend or pulled from a CMS/api?
4. Will language preference be persisted (e.g., via cookies or user settings)?
5. Should we design this with future language support in mind?

Happy to also suggest a remix-compatible approach for scalable multilingual support. Let me know!

[c12i]

Great, would be appreciated. Worth noting that the stream summaries, which we currently get form the db as markdown would either need to be translated in real time from Remix, or pre-translated in advance then stored in the db with a locale prefix, so that the locale can be passed a param to the query.

[c12i]

The web app text content would need to be internationalized, for now lets just support Swahili.

Is there a preferred i18n library or strategy already in place (e.g., remix-i18next)?

No strong preference on any here, just pick the best tool.

Should translations be statically embedded in the frontend or pulled from a CMS/api?

Ideally, though this is dynamic content as I mentioned int he comment above. I think it would be best if the summaries are translated in advance, curious to hear what you think.

Will language preference be persisted (e.g., via cookies or user settings)?

Cookies preferably, the initial language can be inferred from navigator.language

Should we design this with future language support in mind?

Would prefer prioritizing Swahili only for starters

[ayimdomnic]

Thanks for the detailed clarification!

Here’s what I’m thinking in terms of implementation:

1. Web App Internationalization (UI Text)

• Use remix-i18next for SSR-friendly internationalization.
• Store Swahili translations in static JSON files (e.g., locales/en/common.json, locales/sw/common.json).
• Detect navigator.language on the client, and persist the selected locale in a cookie.
• Fallback to English if unsupported language is detected.

2. Stream Summaries

• I agree pre-translating summaries and storing them in the DB is more robust.
• Each summary record can include a locale field (e.g., en, sw) or we could suffix the slug/key.
• Queries would accept a locale param to fetch the appropriate version.
• For fallback, if a sw version doesn’t exist, we can display the English one with a notice.

Would you prefer:

• a single row per summary with { id, enSummary, swSummary }, or
• multiple rows { id, summary, locale }?

Let me know your thoughts on this structure, happy to proceed with a PR setup plan once we align.

[HawiCaesar]

@c12i would you consider some sort of request for suggestions from humans? This is inline with verifying whether the LLM got the translation right, missed some context etc

[c12i]

@HawiCaesar ~Hmmm, I considered this, but this is a manual process that would take a lot of time and effort. Perhaps leveraging a translation model would be much more efficient. I have seen some pretty good models on Hugging Face that do this, but of course, their accuracy will definitely need to be verified, so will that of the actual English summaries.

So yea, come to think of it, a request for suggestions would still be necessary, regardless of the language