docs: Reference new blog article in design principles

docs/pages/docs/design-principles.mdx

@@ -24,11 +24,12 @@ On top of this come typical app problems like:
 
 1. **Rich text formatting**: Many apps need to support some way of rich text, e.g. to embed links into text labels ("Learn more in [the rich text docs](/docs/usage/messages#rich-text).").
 2. **Time zones**: Displaying dates requires consistent handling of time zones across the server and client, potentially even customized based on a preference of the user.
-3. **Relative time formatting**: Displaying relative times like "5 minutes ago" or "in 2 hours" requires special care to get the formatting right, and also to make sure the rendered result is in sync across the server and client. Potentially, you also need a mechanism to update the displayed time regularly.
+3. **Relative time formatting**: Displaying relative times like "5 minutes ago" or "in 2 hours" requires special care to get the formatting right, and also requires a consistent reference value for the current time. Potentially, you also need a mechanism to update the displayed time regularly.
 4. **Localized URLs**: URLs should be localized to match the user's language preference (e.g. `/en/about-us` for English and `/es/sobre-nosotros` for Spanish). Implementation-wise this requires mapping incoming requests to the right pages and providing streamlined APIs for developers to link between pages in a locale-agnostic way.
 5. **Language negotiation**: The user's language preference should be detected based on browser settings, but should also be manually configurable—even if a user hasn't signed in.
 6. **SEO**: Search engines need to be informed about [localized versions of your pages](https://developers.google.com/search/docs/specialty/international/localized-versions) in order to present the best-matching content to your users.
-7. **Country-specifics**: If you provide services or products in different countries, you might need to consider country-specifics like different currencies.
+7. **Country-specifics**: If you provide services or products in different countries, you might need to consider aspects like different currencies and units of measurement.
+8. **Environment differences**: Your components might execute on the server, the client, or both. To achieve [consistent rendering](/blog/date-formatting-nextjs) across different environments, you need to ensure your whole app has unified access to properties like the user locale, time zone and a reference value for the current time.
 
 Considering this list, it might be apparent how large the problem space is and how interconnected different pieces of internationalization are.
 
@@ -84,7 +85,7 @@ Similar to a CMS, you might have data in a backend service or database that need
 
 **Other libraries**
 
-Next.js has a rich ecosystem of libraries that can be used alongside `next-intl`, e.g. to handle authentication. By providing [documentation and examples for common integrations](/docs/routing/middleware#composing-other-middlewares), `next-intl` ensures that you'll have a frictionless experience when integrating with other libraries.
+Next.js has a rich ecosystem of libraries that can be used alongside `next-intl`, e.g. to handle authentication. By providing documentation and examples for [common integrations](/docs/routing/middleware#composing-other-middlewares), `next-intl` ensures that you'll have a frictionless experience when integrating with other libraries.
 
 → [Planned enhancements](https://github.com/amannn/next-intl/labels/area%3A%20integrations)
 
@@ -97,7 +98,7 @@ To achieve this, `next-intl` primarly relies on these techniques currently:
 1. **RSC-first**: By integrating deeply with React Server Components, we can offload work to a build step or a capable server, therefore reducing the runtime footprint of your app on the client side.
 2. **Splitting of messages**: By splitting messages by locale, and optionally also by server, client and component, we can reduce the amount of messages that are sent to the client. This is especially important for apps that support many languages and have a large amount of messages.
 3. **Caching**: Parsing of messages, as well as the instantiation of [`Intl`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl) constructors is cached across your app, therefore reducing the amount of necessary computation.
-4. **Shortcuts**: By detecting plain messages, these messages can be returned immediately without having to parse them first.
+4. **Shortcuts**: Better than caching the result of repetitive work is not doing it in the first place (e.g. by detecting plain messages that don't require parsing).
 
 → [Planned enhancements](https://github.com/amannn/next-intl/labels/area%3A%20performance)