next-multilingual - npm Package Compare versions

Comparing version 0.3.0 to 0.3.1

lib/messages/index.js

		@@ -126,3 +126,2 @@ "use strict";
		// No need to log the error since it was caught when calling `useMessage()`.
		__2.log.warn('uhuh 0 length');
		return '';
		@@ -129,0 +128,0 @@ }

package.json

		{
		"name": "next-multilingual",
		"description": "An opinionated end-to-end multilingual solution for Next.js.",
		"version": "0.3.0",
		"version": "0.3.1",
		"license": "MIT",
		@@ -6,0 +6,0 @@ "main": "lib/index.js",

README.md

		@@ -5,5 +5,5 @@ # ![next-multilingual](./assets/next-multilingual-banner.svg)

		Check out our [demo app](https://next-multilingual-example.avansai.com)!
		Check out our [demo app](https://next-multilingual-example.vercel.app)!

		[![Try me](https://img.shields.io/badge/-Try%20me!-green?style=for-the-badge)](https://next-multilingual-example.avansai.com)
		[![Try me](https://img.shields.io/badge/-Try%20me!-green?style=for-the-badge)](https://next-multilingual-example.vercel.app)

		@@ -30,3 +30,3 @@

		Also, having an opinion on "best practices" is not an easy task. This is why we documented our design decisions in a special document that can be consulted [here](./docs/design-decisions.md). If you feel that some of our APIs don't offer what you would expect, make sure to take a peek at this document before opening an issue.
		Also, having an opinion on "best practices" is not an easy task. This is why we documented our design decisions in a special document that can be consulted [here](./docs/design-decisions.md). If you feel that some of our APIs don't offer what you would expect, make sure to consult this document before opening an issue.

		@@ -53,3 +53,3 @@ ## Getting Started 💨
		- `applicationIdentifier` — The unique application identifier that will be used as a messages key prefix.
		- `locales` — The actual desired locales of the multilingual application. The first locale will be the default locale. Only BCP 47 language tags following the `language`-`country` format are accepted. For more details on why, refer to the [design decisions](../../docs/design-decisions.md) document.
		- `locales` — The actual desired locales of the multilingual application. The first locale will be the default locale. Only BCP 47 language tags following the `language`-`country` format are accepted. For more details on why, refer to the [design decisions](./docs/design-decisions.md) document.
		- `options` (optional) — Options part of a [Next.js configuration](https://nextjs.org/docs/api-reference/next.config.js/introduction) object.
		@@ -158,3 +158,3 @@ - Also a few other arguments you probably will never need to use - check in your IDE (JSDoc) for more details.

		You might have noticed the `getActualDefaultLocale` API. his API is part of a [set of "utility" APIs](./src/index.ts) that helps abstract some of the complexity that we configured in Next.js. These APIs are very important, since we can no longer rely on the locales provided by Next.js. The main reason for this is that we set the default Next.js locale to `mul` (for multilingual) to allow us to do the dynamic detection on the homepage. These APIs are simple and more details are available in your IDE (JSDoc).
		You might have noticed the `getActualDefaultLocale` API. This API is part of a [set of "utility" APIs](./src/index.ts) that helps abstract some of the complexity that we configured in Next.js. These APIs are very important, since we can no longer rely on the locales provided by Next.js. The main reason for this is that we set the default Next.js locale to `mul` (for multilingual) to allow us to do the dynamic detection on the homepage. These APIs are simple and more details are available in your IDE (JSDoc).

		@@ -193,11 +193,11 @@ ### Create a custom `Document` (`_document.tsx`)

		This serves only 1 purpose: display the correct server-side locale in the `<html>` tag. Since we are using a "fake" default locale, it's important to keep the correct SSR markup, especially when resolving a dynamic locale on `/`. The `normalizeLocale` is not mandatory but a recommended ISO 3166 convention. Since Next.js uses the locales as URLs prefixes, they are lower-cased in the configuration and can be re-normalized as needed.
		This serves only 1 purpose: display the correct server-side locale in the `<html>` tag. Since we are using a "fake" default locale, it's important to keep the correct SSR markup, especially when resolving a dynamic locale on `/`. The `normalizeLocale` is not mandatory but a recommended ISO 3166 convention. Since Next.js uses the locales as URL prefixes, they are lower-cased in the configuration and can be re-normalized as needed.

		### Configure all your pages to use SEO friendly markup

		`next-multilingual/head` provides a `<MulHead>` component will automatically creates a canonical link and alternate links in the header. This is something that is not provided out of the box by Next.js.
		`next-multilingual/head` provides a `<MulHead>` component which automatically creates a canonical link and alternate links in the header. This is something that is not provided out of the box by Next.js.

		#### Add a `NEXT_PUBLIC_ORIGIN` environment variable

		As per [Google](https://developers.google.com/search/docs/advanced/crawling/localized-versions), alternate links must be fully-qualified, including the transport method (http/https). Because Next.js does not know which URL is used at build time, we need to specify the absolute URLs that will be used, in an [environment variable](https://nextjs.org/docs/basic-features/environment-variables). For example, for the development environment, create an `.env.development` file at the root of your application with the following variable (adjust based on your setup):
		As per [Google](https://developers.google.com/search/docs/advanced/crawling/localized-versions), alternate links must be fully-qualified, including the transport method (http/https). Because Next.js does not know which URL is used at build time, we need to specify the absolute URL that will be used, in an [environment variable](https://nextjs.org/docs/basic-features/environment-variables). For example, for the development environment, create an `.env.development` file at the root of your application with the following variable (adjust based on your setup):

		@@ -208,3 +208,3 @@ ```ini

		Regardless of the environment, `next-multilingual` will look for a variables called `NEXT_PUBLIC_ORIGIN` to generate fully-qualified URLs. If you are using Next.js' [`basePath`](https://nextjs.org/docs/api-reference/next.config.js/basepath), it will be added automatically to the base URL.
		Regardless of the environment, `next-multilingual` will look for a variable called `NEXT_PUBLIC_ORIGIN` to generate fully-qualified URLs. If you are using Next.js' [`basePath`](https://nextjs.org/docs/api-reference/next.config.js/basepath), it will be added automatically to the base URL.

		@@ -221,3 +221,3 @@ `NEXT_PUBLIC_ORIGIN` will only accept fully qualified domains (e.g. `http://example.com`), without any paths.

		- Redirecting on `/` can have negative SEO impact, and is not the best user experience.
		- Redirecting on `/` can have negative SEO impact and is not the best user experience.
		- `next-multilingual` comes with a `getPreferredLocale` API that offers smarter auto-detection than the default Next.js implementation.
		@@ -304,7 +304,7 @@

		Every time that you create a `tsx`, `ts`, `jsx` or `js` file and that you need localized messages, you can simply create messages file in your supported locales that will only be usable by these files. Just like CSS modules, the idea is that you can have message files associated to another file's local scope. This has the benefit to make messages more modular and also not share messages across different context (more details in the [design decisions document](./docs/design-decisions.md) on why this is bad).
		Every time that you create a `tsx`, `ts`, `jsx` or `js` file and that you need localized messages, you can simply create a message file in your supported locales that will only be usable by these files. Just like CSS modules, the idea is that you can have message files associated to another file's local scope. This has the benefit to make messages more modular and also not share messages across different context (more details in the [design decisions document](./docs/design-decisions.md) on why this is bad).

		There are two uses cases for messages files:
		There are two uses cases for message files:

		- For the messages files in your `pages` directory, they will determine what the URL segment (part of a URL in between `/`) of this page is using the `pageTitle` key identifier. On top of that, they will be used as local scope messages if there are messages required specific to that page.
		- For the message's files in your `pages` directory, they will determine what the URL segment (part of a URL in between `/`) of this page is using the `pageTitle` key identifier. On top of that, they will be used as local scope messages if there are messages required specific to that page.
		- They will store all the localizable strings (messages) used by your application. Note that you should only put the message used in the page directly since components also have their own message files. Those messages will be used by the `useMessages` hook and will only be available in local scopes. Imagine CSS but for localizable stings.
		@@ -314,3 +314,3 @@

		- Messages are associated to a file, and should only be used in that local scope.
		- Messages are associated to a file and should only be used in that local scope.
		- Messages are used both to localize URLs and to display localized text everywhere in your application.
		@@ -321,5 +321,5 @@ - You should only use this method in your application to simplify your localization process.

		Creating and managing those files are as simple as creating a style sheet, but here are the important details:
		Creating and managing those files is as simple as creating a style sheet, but here are the important details:

		- The message files are `.properties` file. Yes, you might wonder why, but there are good reasons documented in the [design decision document](./docs/design-decisions.md).
		- The message files are `.properties` files. Yes, you might wonder why, but there are good reasons documented in the [design decision document](./docs/design-decisions.md).
		- To leverage some of the built-in IDE support for `.properties` files, we follow a strict naming convention: `<Page-Name>.<locale>.properties`
		@@ -331,11 +331,11 @@ - Each message must have unique keys that follow a strict naming convention: `<application identifier>.<context>.<id>` where:
		- Each "segment" of a key must be separated by a `.` and can only contain between 3 to 50 alphanumerical characters - we recommend using camel case for readability.
		- For pages, if you want to localize your URLs, you must include messages files that include a key with the `pageTitle` identifier.
		- For pages, if you want to localize your URLs, you must include message files that include a key with the `pageTitle` identifier.
		- For components, files are only required if you use the `useMessages` hook.
		- For messages shared across multiple components (shared messages), you need to create a "shared message component" (more details no this below)
		- For messages shared across multiple components (shared messages), you need to create a "shared message component" (more details on this below)

		Also, make sur to check your console log for warnings about potential issues with your messages. It can be tricky to get used to how it works first, but we tried to make it really easy to detect and fix problems. Note that those logs will only show in non-production environments.
		Also, make sure to check your console log for warnings about potential issues with your messages. It can be tricky to get used to how it works first, but we tried to make it easy to detect and fix problems. Note that those logs will only show in non-production environments.

		#### Using messages for localized URLs

		Also, as mentioned previously, there is one special key for `pages`, where the `id` is `pageTitle`. This message will be used both as a page title, but also as the localized URL segment of that page. Basically the "page title" is the human readable "short description" of your pages, and also represents a segment (contained between slashes) of a URL. When used as a URL segment, following changes are applied:
		Also, as mentioned previously, there is one special key for `pages`, where the `id` is `pageTitle`. This message will be used both as a page title, but also as the localized URL segment of that page. Basically the "page title" is the human readable "short description" of your page, and represents a segment (contained between slashes) of a URL. When used as a URL segment, following changes are applied:

		@@ -345,11 +345,11 @@ - all characters will be lowercased

		For example `About us` will become `about-us`. For the homepage, the URL will always be `/` which means that `pageTitle` will not be used to create URL segments.
		For example, `About us` will become `about-us`. For the homepage, the URL will always be `/` which means that `pageTitle` will not be used to create URL segments.

		> ⚠️ Note that if you change `pageTitle`, this means that the URL will change. Since those changes are happening in `next.config.js`, like any Next.js config change, the server must be restarted to see the changes in effect. The same applies if you change the folder structure since the underlying configuration relies on this.

		If you want to have a directory without any pages, you can still localize it by creating an `index.<locale>.properties` files (where `locale` are the locales you support). We don't really recommend this as this will make URL paths longer which goes against SEO best practice. But the option remains in case it is necessary.
		If you want to have a directory without any pages, you can still localize it by creating an `index.<locale>.properties` file (where `locale` are the locales you support). We don't really recommend this as this will make URL paths longer which goes against SEO best practice. But the option remains in case it is necessary.

		#### What do messages file look like?
		#### What do message files look like?

		You can always look into the [example](./example) too see messages files in action, but here is a sample that could be used on the homepage:
		You can always look into the [example](./example) to see message files in action, but here is a sample that could be used on the homepage:

		@@ -364,3 +364,3 @@ ```properties

		Now that we learned how to create the homepage and some the details around how things work, we can easily create other pages. We create many pages in the [example](./example) , but here is a sample of what `about-us.jsx` could look like:
		Now that we learned how to create the homepage and some of the details around how things work, we can easily create other pages. We create many pages in the [example](./example), but here is a sample of what `about-us.jsx` could look like:

		@@ -383,3 +383,3 @@ ```jsx

		And of course you would have its message file `about-us.en-US.properties`:
		And of course you would have this message file `about-us.en-US.properties`:

		@@ -393,3 +393,3 @@ ```properties

		`next-multilingual` comes with its own `<MulLink>` component that allow for client side and server side rendering of localized URL. It's usage is simple, it works exactly like Next.js' [`<Link>`](https://nextjs.org/docs/api-reference/next/link).
		`next-multilingual` comes with its own `<MulLink>` component that allows for client side and server side rendering of localized URL. It's usage is simple, it works exactly like Next.js' [`<Link>`](https://nextjs.org/docs/api-reference/next/link).

		@@ -416,3 +416,3 @@ The only important thing to remember is that the `href` attribute should always contain the Next.js URL. Meaning, the file structure under the `pages` folder should be what is used and not the localized versions.

		In English the URL path will be `/en-us/contact-us`. But in when another locale is selected, you will get the localized URLs paths. See the example below for when `fr-ca` is selected:
		In English the URL path will be `/en-us/contact-us`. But when another locale is selected, you will get the localized URLs path. See the example below for when `fr-ca` is selected:

		@@ -429,3 +429,3 @@ ```html

		Creating components is exactly the same as pages but they live outside the `pages` folder. Also as mentioned previously you do not need to add the `pageTitle` key. We have a few [example components](./example/components) that should be self explanatory but here is an example of a `Footer.tsx` component:
		Creating components is the same as pages but they live outside the `pages` folder. Also as mentioned previously you do not need to add the `pageTitle` key. We have a few [example components](./example/components) that should be self explanatory but here is an example of a `Footer.tsx` component:

		@@ -457,7 +457,7 @@ ```tsx

		We've been pretty clear that sharing messages is a bad practice from the beginning, so what are we talking about here? In fact, sharing messages by itself is not bad. What can cause problems if when you share messages in different context. For example you might be tempted to create a `Button.ts` shared message file containing `yesButton`, `noButton` keys - but this would be wrong. In many languages simple words as "yes" and "no" can have different spellings depending on the context, even if it's a button.
		We've been clear that sharing messages is a bad practice from the beginning, so what are we talking about here? In fact, sharing messages by itself is not bad. What can cause problems is when you share messages in different contexts. For example, you might be tempted to create a `Button.ts` shared message file containing `yesButton`, `noButton` keys - but this would be wrong. In many languages simple words as "yes" and "no" can have different spellings depending on the context, even if it's a button.

		So when is it good to share messages? For list of items.
		When is it good to share messages? For list of items.

		For example, to keep your localization process simple, you want to avoid as much as possible storing localizable strings in your database (more details on why in the [design decision document](./docs/design-decisions.md)). So in your database you would identify the context using unique identifiers and you would store your messages in shared messages files, where your key's identifiers would match the ones from the database.
		For example, to keep your localization process simple, you want to avoid as much as possible storing localizable strings in your database (more details on why in the [design decision document](./docs/design-decisions.md)). In your database you would identify the context using unique identifiers and you would store your messages in shared message files, where your key's identifiers would match the ones from the database.

		@@ -472,3 +472,3 @@ To illustrate this we created [one example using fruits](./example/messages/Fruits.ts). All you need to do, is create a component that calls `useMessages` like this:

		Of course you will have your messages files in the same directory:
		Of course, you will have your messages files in the same directory:

		@@ -512,3 +512,3 @@ ```properties

		The idea to share those list of items is that you can have a consistent experience across different components. Imagine a dropdown with a list of fruit in one page, and in another page an auto-complete input. But the important part to remember is that the list must always be used in the same context, not to re-use some of the messages in different context.
		The idea to share those lists of items is that you can have a consistent experience across different components. Imagine a dropdown with a list of fruits in one page, and in another page an auto-complete input. But the important part to remember is that the list must always be used in the same context, not to re-use some of the messages in a different context.

		@@ -533,3 +533,3 @@ ### Message Variables

		One of the main benefit of ICU MessageFormat is to use Unicode's tools and standards to enable applications to sound fluent in most languages. A lot of engineers might believe that by having 2 messages, one for singular and one for plural is enough to stay fluent in all languages. In fact, Unicode documented the [plural rules](https://unicode-org.github.io/cldr-staging/charts/latest/supplemental/language_plural_rules.html) of over 200 languages and some languages like Arabic an have up to 6 plural forms.
		One of the main benefits of ICU MessageFormat is to use Unicode's tools and standards to enable applications to sound fluent in most languages. A lot of engineers might believe that by having 2 messages, one for singular and one for plural is enough to stay fluent in all languages. In fact, Unicode documented the [plural rules](https://unicode-org.github.io/cldr-staging/charts/latest/supplemental/language_plural_rules.html) of over 200 languages and some languages like Arabic an have up to 6 plural forms.

		@@ -587,3 +587,3 @@ To ensure that your sentence will stay fluent in all languages, you can use the following message:

		Like most site, you will want to leverage Next.js' [custom your error pages](https://nextjs.org/docs/advanced-features/custom-error-page) capability. With `useMessages()`, it's just as easy as creating any other pages. For example, for a `404` error, you can create your `404.tsx`:
		Like most site, you will want to leverage Next.js' [custom error pages](https://nextjs.org/docs/advanced-features/custom-error-page) capability. With `useMessages()`, it's just as easy as creating any other pages. For example, for a `404` error, you can create your `404.tsx`:

		@@ -618,6 +618,6 @@ ```tsx

		Our ideal translation process is one where you send the modified files to your localization vendor (while working in a branch), and get back the translated files, with the correct locale in the filenames. Once you get the files back you basically submit them back in your branch which means localization becomes integral part of the development process. Basically the idea is:
		Our ideal translation process is one where you send the modified files to your localization vendor (while working in a branch), and get back the translated files, with the correct locale in the filenames. Once you get the files back you basically submit them back in your branch which means localization becomes integral part of the development process. Basically, the idea is:

		- Don't modify the files, let the translation management system (TMS) do its job.
		- Add a localization step in you development pipeline and wait for that step to be over before merging back to your main branch.
		- Add a localization step in your development pipeline and wait for that step to be over before merging back to your main branch.

		@@ -628,8 +628,8 @@ We don't have any "export/import" tool to help as at the time of writing this document.

		Why did we put so much efforts with these details? Because our hypothesis is that it can have a major impact on:
		Why did we put so much effort with these details? Because our hypothesis is that it can have a major impact on:

		- SEO;
		- boosting customer trust with more locally relevant content;
		- making string management easier and more modular.
		- SEO
		- Boosting customer trust with more locally relevant content.
		- Making string management easier and more modular.

		More details an be found on the implementation and design decision in the individual README files of each API and in the [documentation](./doc) directory.
		More details an be found on the implementation and design decision in the individual README files of each API and in the [documentation](./doc) directory.

next-multilingual - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics

Worsened metrics