Security News
tea.xyz Spam Plagues npm and RubyGems Package Registries
Tea.xyz, a crypto project aimed at rewarding open source contributions, is once again facing backlash due to an influx of spam packages flooding public package registries.
@leile/lobo-t
Advanced tools
Readme
A small library for type-safe translations in React applications
$ npm i @leile/lobo-t
# or
$ yarn add @leile/lobo-t
lobo-t
at a glanceYou tell lobo-t
which languages you support and which language is currently active.
lobo-t
gives you a React hook that you can use to get a function for translating text resources.
A text resource in lobo-t
terms is an object that has keys for each language you support.
If you try to translate a text resource that is missing one or more languages or a text resource that doesn't exist, lobo-t
(or rather, TypeScript) will tell you so.
That's all.
If you want to know more about why we decided to make this, see below.
// i18n.ts
import { initLobot } from '@leile/lobo-t';
// Specify which languages you support
export enum Language {
Norwegian = 'nb',
English = 'en',
}
const lobot = initLobot<typeof Language>(Language.English);
export const LanguageProvider = lobot.LanguageProvider;
export const useTranslation = lobot.useTranslation;
// index.tsx
import { LanguageProvider, Language } from './i18n';
import App from './App';
// You decide how to detect/store the active language.
// In this example, we get it as a prop.
// When it changes, components using the useTranslation hook will re-render with the correct language
export default (props: { activeLanguage: Language }) => (
<LanguageProvider value={props.activeLanguage}>
<App />
</LanguageProvider>
);
// App.tsx
import { useTranslation } from './i18n';
// Text resources must have a key for each language you support
const texts = {
header: {
nb: 'Dette er en header',
en: 'This is a header',
},
activeUsers: count => ({
nb: `Det er nå ${count} aktive brukere`,
en: `There are now ${count} active users`,
}),
// or
// header: {
// [Language.Norwegian]: 'Dette er en header',
// [Language.English]: 'This is a header',
// },
// activeUsers: count => ({
// [Language.Norwegian]: `Det er nå ${count} aktive brukere`,
// [Language.English]: `There are now ${count} active users`,
// }),
};
export default () => {
const { t } = useTranslation();
return (
<div>
<h1>{t(texts.header)}</h1>
<p>{t(texts.activeUsers(5))}</p>
</div>
);
};
After using other translation libraries for quite some time we realized that we didn't really like them. They worked, but there were some things that irked us. For example:
{{somevariablename}}
in strings and passing objects with properties that should match whatever you wrote in the translation file is an error waiting to happen.So we sat down and came up with a list of what we wanted. For context, most of our applications are written using next.js, all of them in TypeScript, and at the moment we support two languages. Since we use next.js we get code splitting out of the box, so we don't really need our internationalization tool to have complex lazy-loading features. Additionally, we, the developers, are the ones writing the translations.
We like the way CSS modules allow us to scope our CSS so that changes in one part of the application don't break other stuff. It would be nice to be able to apply the same principle to internationalization.
The save button should communicate to the user that it will save, no matter what language the user is using. It should not say "Save" in English and "Fullfør" (which means "Complete") in Norwegian. Keeping the English and Norwegian texts close together, rather than in separate files in separate folders, helps us keep semantics in check.
When using a text resource that expects some external input you should be notified of this before leaving your editor/IDE.
Sometimes it makes sense to have some styling in the text resource. This could be done either with inline HTML/JSX or using markdown in some way.
For example, in our opinion:
const myText = <span>String with a <strong>bold</strong> word.</span>
/// ...
<div>{myTextResource}</div>
is easier and less error-prone than
const myTextOne = 'String with a';
const myTextTwo = 'bold';
const myTextThree = ' word';
// ...
<div>
{myTextOne}
<strong>{myTextTwo}</strong>
{myTextThree}
</div>;
In the second example, can you tell at a glance whether this wil render with the correct whitespace or not?
FAQs
A simple library for type-safe translations
The npm package @leile/lobo-t receives a total of 239 weekly downloads. As such, @leile/lobo-t popularity was classified as not popular.
We found that @leile/lobo-t demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Tea.xyz, a crypto project aimed at rewarding open source contributions, is once again facing backlash due to an influx of spam packages flooding public package registries.
Security News
As cyber threats become more autonomous, AI-powered defenses are crucial for businesses to stay ahead of attackers who can exploit software vulnerabilities at scale.
Security News
UnitedHealth Group disclosed that the ransomware attack on Change Healthcare compromised protected health information for millions in the U.S., with estimated costs to the company expected to reach $1 billion.