Forem: Vadorequest

SendGrid is deceptive about "Opened emails" statistic

Vadorequest — Sat, 26 Nov 2022 18:02:08 +0000

After in-depth analysis of SendGrid system, I came to the following conclusions:

Their "open" event is not accurate, as it can be trigger by either a BOT or a human
They know this (and have built their analytics dashboard, knowingly or unknowingly, so that it doesn't reflect this issue)

On the above screenshot, you can see that 46 emails are being opened within 100 seconds exactly. There were 96 recipients in total, so that'd mean about 50% opened the email right away?
That's odd, isn't?

But let's do more testing:

On this batch, we got even better numbers!
66 recipients, 52 of them opened the email within 40 seconds. 🎉

Our marketing team must be awesome, and our product terrific for such quick enthusiasm!
Well, except the "click" rate is ... 1%. Odd, isn't?

But how does that "open" event works, by the way?

It's simple. SendGrid adds a "pixel" in the email, basically an image which points to a script. Whenever that script is being downloaded, it means the email has been opened. Simple!
This might not be 100% accurate, but you get the big picture.

👉 SendGrid doesn't know that you've opened the email by actually clicking on it, they only know that it has been opened.

And what else could open our emails? 🤔

Well, you guessed it (probably): SPAM checkers, and any other "AI" that would read the email content (like Gmail, to know whether to store it into your "Promotion" inbox and all of that).

In conclusion, SendGrid cannot make the difference between an email opened by an actual human, or by a bot!

And that would be fine, it they weren't trying to hide it. (or at least, make it obvious that this information is not 100% accurate!)

Companies use KPIs to run a business, and sometimes, those KPIs are "how many people are reading our newsletter?". Well, when you make strategic decisions like that based on deceptive information, it can hurt.

Following this analysis, I've contacted the "Trust & safety" team at SendGrid with a few advices on how to be more transparent about this fact, and decided to write a public article about it.

I believe companies should put transparency over growth.
Don't just hide your problems, but fix it instead, or at least tell us about it.

N.B: I bet other "Email delivery providers" have the exact same issue, and are deceptive, too.

P.S: I hope nobody got fired "for doing a bad job" because their email campaign had a 1% clicks out of 80% reads. But, murphy law, right?

A 2021 guide about structuring your Next.js project in a flexible and efficient way

Vadorequest — Thu, 21 Jan 2021 14:15:27 +0000

Next.js

Next.js is very unopinionated about how to structure your Next.js project.

The only thing you must really be careful about is to not have anything under pages that aren't actual pages (e.g: tests, components, etc.), because there is no way to ignore them and Next will bundle and deploy them as actual pages.

You can choose to have your code at the root level (/pages) or under src (/src/pages). We prefer the latter, because it makes it more obvious what is actual app-related code and what isn't.

The usual folder structure

Most people will organize their project using a folder structure such as:

/public
    favicon.ico
/src
    /components
        /elements
            /auth
                AuthForm.tsx
                AuthForm.test.ts
            /[Name]
                [Name].tsx
                [Name].test.ts
    /hooks
    /types
    /utils
    /test
        /api
            authAPI.test.js
            [name]API.test.js
        /pages
            index.test.js

    /pages
        /api
          /authAPI
              authAPI.js
          /[name]API
              [name]API.js
        _app.tsx
        _document.tsx
        index.tsx

This design pattern is very common, and it's great for small project because it makes it obvious where your files should be located. They're grouped by "kind of files". It's very similar to the MVC design pattern many developers are familiar with.

The main issue with this design pattern is its lack of scalability.

While it's great at the beginning, and can be a good fit depending on the size of your project, you'll realize a some point you'd find your files faster if they were grouped together by "module".

Once you reach 6-10 unrelated features, you'll wish to have the components files close to the utilities and to the TS type that are specific to your UI components, or even maybe your data model.

Also, you might prefer having all files related to a particular 3rd party within the same folder, as a module. (e.g: Sentry, Amplitude, etc.)

At some point, splitting files based on their kind will not be good enough. That's where you'll need modules.

The flexible and "modular" folder structure

Another way to organize things is to introduce modules.
Modules help group together code that is related to each other. They're not a replacement for what's common.

Here is how we might convert our previous folder structure to something a bit more modular:

/public
    favicon.ico
/src
    /common
        /components
            /elements
                /[Name]
                    [Name].tsx
                    [Name].test.ts
        /hooks
        /types
        /utils
    /modules
        /auth
            /api
                AuthAPI.js
                AuthAPI.test.js
            /components
                AuthForm.tsx
                AuthForm.test.ts
            auth.js
    /pages
        /api
          /authAPI
              authAPI.js
          /[Name]API
              [Name]API.js
        _app.tsx
        _document.tsx
        index.tsx

We added a new src/modules/ folder where we group all files related to the same feature (here, the authentication as "auth"), instead of splitting the "auth" code everywhere, it is now centralized into a single folder.

You might have noticed the only thing that hasn't changed is the src/pages/ directory. I'll repeat myself, but you must not have anything there that isn't either a page or an API endpoint.

Everything related to the authentication is now in /src/modules/auth, it's much easier/faster to understand the code being used to authenticate now!

But, you don't want to always use modules, right? Sometimes you're writing some kind of utility that doesn't really fit in any module, something you'll want to write some code quickly and be done with it.

Modules introduce "thoughts complexity", because now you have a conscious choice to make about where your file should be. It was easier before to make this decision, because grouping files by kind is effortless, it's a choice that has an actual answer to it. Moving a component to the hooks folder is wrong, while moving it to the components is correct.

It's easy to know you did it right. (or wrong)

But, with modules, there is no right/wrong answer! Making it harder to make decisions. Sometimes you won't know, it won't be obvious at first (it may never be). Sometimes you'll figure it out afterwards ("oh, that's actually a module").

And because modules aren't the universal solution to this problem, the key is to allow both.

The common directory should be used for everything that isn't a module, while the modules directory should be used by everything you feel should be a "module".

This way, you get the best of both worlds:

The ability to quickly add code without thinking much about where it should be (common).
The ability to organize at your own pace when you feel like that thing has grown too big and all those pieces of code should be brought together (converting from common to modules).
The ability to quickly find your code in your existing modules and to have an overview of how big a module is.

I'm the author of Next Right Now, a Next.js production-ready boilerplate, and the above folder structure is what we're using since January 20, 2021. It is the result of feedbacks from the NRN community.

Alongside this new folder structure, Next Right Now has also migrated to "Module path aliases", which uses absolute paths instead of relative paths for importing modules. (e.g: import ('@/common/hooks/useStuff') instead of import ('../../../common/hooks/useStuff').

If you want to learn more on the topic, read the NRN folder structure documentation!

Migrating Next.js (+Jest/Storybook/Cypress) to use module path aliases, instead of relative paths

Vadorequest — Mon, 18 Jan 2021 12:20:27 +0000

Most projects use the well-known relative paths to resolve files and modules. For instance: import '../config.ts';

Sometimes, especially on big project, it becomes this:
import { NRN_DEFAULT_THEME } from '../../common/constants';

But, did you know you can convert to something like this:
import { NRN_DEFAULT_THEME } from '@/common/constants';

This is a "module path alias", and Next.js has support for those since 9.4 (May, 2020).

The main advantages to module path aliases are:

Avoids "../" spaghetti code
Avoid breaking your imports when moving them around (sure, IDE help but when you move a lot of files around, they get confused too)
Avoid changing the file content when moving the file around, which in turn leads to avoiding Git conflicts! (this is, by far, the main advantage, IMHO)
You can copy/paste your code, and it'll work as-it, even if you pasted it into a file on another folder level (and that's great)
You can still use relative imports if you want, it's not a lock-in!
Do you see more?

So, why not using them? Why don't we see that more often?

It requires configuration in several tools (babel, webpack)
It affects all tools in your project, because all file loaders must be compatible, and configured properly (this is, by far, the main reason why it's so complicated to get right)

If you use a very simple Next.js project, you can simply change your tsconfig.json to something like this:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/common/*": [
        "src/common/*"
      ],
      "@/components/*": [
        "src/common/components/*"
      ],
      "@/utils/*": [
        "src/common/utils/*"
      ],
      "@/modules/*": [
        "src/modules/*"
      ]
    },

The above mapping is what we're thinking of using in Next Right Now, but you probably want something specific to your app and way of doing things!

Using a mapping as described above will be enough for Next.js to use import { NRN_DEFAULT_THEME } from '@/common/constants'; properly!

How to convert all relative paths to module paths?

The relative-to-alias NPM module helped us a ton.

It was hard to configure properly because it wasn't doing anything at first (due to a misconfiguration on our side), but we eventually managed to make it work.

npx relative-to-alias --src 'src' --alias '@/common' --alias-path './src/common' --extensions 'ts,tsx' --language 'typescript'

Running this replaced all relative paths to @/common/.... We eventually wrote a script for this.

This is a quick and easy way to migrate an existing project.

Make sure to commit all changes before running the codemod:module-path-aliases! It'll change lots of files and should be done in a dedicated commit/PR.

Is that it?

Depending on how big your project is, it might... But:

If you're using Jest (you probably are)
If you're using Cypress
If you're using Storybook

Then, you'll need to configure them, so they understand what @/ means!

And, unfortunately, that's the most complicated part to figure out by yourself... Because they all use a different way of doing so. They don't all rely on tsconfig.json, and you don't necessarily only use TypeScript, but JavaScript as well!

Here is an overview of where you'll need to make changes:

The jsconfig.json are necessary for WebStorm to resolve the aliases used within .js files. (Otherwise, it compiles but WebStorm displays "Module not found")

Jest has a particular way to understand aliases. Storybook doesn't have tsconfig.json and it must be configured via their Webpack override.

In conclusion, it can be quite complicated (with a lot of duplicated configuration) to make Module aliases work on a whole project. It takes some time to understand how each 3rd party needs to be configured.

At this time, I don't have any feedback experience regarding actual usage. This is still under peer-review, and it might take a while until we get familiar with those new paths.

Also, it is concerning how complicated the configuration is. It's being duplicated in no less than 7 different files! And one might be concerned about what'd happen if it ever breaks.

But, in such event, I guess we can solve it with another codemod that converts all module aliases back to relative paths!

Using Storybook 6.1 with Next.js and Emotion 11 - Advanced usage and best practices

Vadorequest — Sun, 17 Jan 2021 14:11:30 +0000

The Next Right Now boilerplate recently got an interesting upgrade!

Overview

We've added Storybook side-by-side with our Next.js application. It took us about 4 days of intensive work.

We had never used Storybook in the past, and we were looking for a Design System to help our designers and developers build components in a better way, with proper documentation, functional testing, accessibility testing, and interact with our components. Storybook helped us achieve all of that - and even a bit more.

While this work has been done on Next Right Now, any Next.js project can benefit from it.

Check out the Pull Request and documentation to learn more about it.

Check out the result on our Storybook demo.

Main features

Compatible with TypeScript
Compatible with Emotion 10/11, useful if you use Emotion yourself, or libs using Emotion
Next.js router (decorator)
Compatible with Sentry
Compatible with node-related libs
Compatible with CSS Modules
Static site automatically deployed on Vercel, using GitHub Actions
Automated tests using Cypress, to make sure you get warned if you accidenly break your static site
Support for i18next and Locize provider (fetched and cached upon build)

Methodology and learnings

Initial configuration

It wasn't easy. The most difficult part was Emotion/Node.js, because it required some Webpack/Babel tricks with solutions and workarounds splattered all over the web. Emotion was quite a pain in particular, because their TS types clash between v10 and v11. Next Right Now had been upgraded to v11 last week, but some libraries we use are still using v10, which creates a few inconsistencies, even after configuring Webpack and Babel as recommended.

Definitely not something easy to do. It took us about one and half day of work to get it right. Also, we directly integrated automated deployments (CI/CD) using Vercel and GitHub Actions. That part was easy because we have quite a lot of experience with those already.

Build a solid Storybook foundation

Once all the pieces had been properly configured, we started looking at the Storybook ecosystem. We wasted 2 good hours trying to use knobs before we figured it wasn't the recommended way to do things anymore. (Replaced by controls in v6)

The https://storybook.js.org/addons/ was great to get an overview of all existing addons, and we went through the whole list, to look at all those that were promising. Eventually, we selected 8 officials and 5 community-maintained. Checking all of them took us another day.

    // Officials
    "@storybook/addon-a11y": "6.1.14",
    "@storybook/addon-actions": "6.1.14",
    "@storybook/addon-console": "1.2.2",
    "@storybook/addon-essentials": "6.1.14",
    "@storybook/addon-google-analytics": "6.1.14",
    "@storybook/addon-jest": "6.1.14",
    "@storybook/addon-links": "6.1.14",
    "@storybook/addon-storysource": "6.1.14",

    // Community
    "storybook-addon-designs": "5.4.3",
    "storybook-addon-next-router": "2.0.3",
    "storybook-addon-performance": "0.14.0",
    "storybook-css-modules-preset": "1.0.5",
    "storybook-mobile": "0.1.29",

We documented them all in the .storybook/main.js file

Those addons were "must-haves" to us. Eventually, we disabled storysource and we don't actually use performance much yet, but it looks promising.

Storybook has a special essentials package regrouping all the "essential" features, it definitely helped us! (but we're greedy and wanted more!)

Mock our app behavior

And then, we had to mock stuff around, using Decorators, configuring i18n with Locize so our components could behave in Storybook the same way they behave in Next Right Now. Overall, it wasn't so hard, but took time to get right.

Writing actual component Stories

Once we were done with the configuration part (around 2.5 days in total), it was time to do the actual work: Write stories for ALL our components.

And... it was hard. We had written a few stories during the configuration (of course!) and we knew the basics, but it wasn't obvious what were the "Best practices" really. Also, looking at stuff on the web didn't help and was quite confusing, as they were plenty of examples using v4 or v5, and not many using v6 (which is still quite new!).

At some point, we figured how we'd write our components in such a way we'd avoid code duplication (within stories). But it took us much longer than we wished to.

To be honest, we don't really know if our way is "the" way. It's one that makes sense, avoids code duplication, is simple to maintain and extend.

Is it good? Definitely.
It is the best? You tell me.

Eventually, we managed to write stories for all our components. It took us about 2.5 days.

Caveats and pains

Babel/Webpack are real pains. They're like a double edge sword, either you figure out how to configure stuff or you don't. If you do, great, you can now work on the real stuff. If you don't, well, you suck. Or that's actually what it feels like. Personally, I hate configuring Babel/Webpack, because I'm not familiar with them, and I don't want to learn them either. They're too complicated for my taste, and they evolve with breaking changes too often, too. I don't know why it was so complicated, it just was, and it could have been avoided.
Storybook documentation is good, but it's not great yet. We got lost several times about how to write our components, met a few bugs that made us feel dumb (hello .storybook/manager.js with your broken cache), had to go around and around the documentation to find how to configure default stories, override stories, how to disable controls for properties (we eventually wrote a withPropMock HOC for this). TS helps a ton, but there are yet quite a bit of uncovered documentation. They're working on it, and we've seen far worse. Overall, we had a good experience, but it can improve!
Some stuff that should be simple (like sharing CSS for all stories) was quite complicated and really not developer-friendly.
We ended up re-writing our stories completely several times, until we found the "right" way.

Final words

Adding Storybook was exciting, a bit needlessly complicated, but the result is great. It's going to be tremendously helpful for our Product Owner, Designers and Developers to collaborate at Unly, and the team is very excited to benefit from this update once we'll ship it into our private Next Right Now forks!

Having experienced a bit of Storybook v5 and v6, the v6 provides a much better developer experience, great job to the team, it's lovely to see OSS building such great products!

Next Right Now in 2020 - Most flexible and production-ready boilerplate for Next.js

Vadorequest — Sat, 09 Jan 2021 19:20:52 +0000

Next Right Now is a production-ready boilerplate for Next.js.

Authored by Unly less than a year ago, it has recently reached 500 GitHub stars, with more than 1000 unique visitors in December 2020 alone!

Our main motivation by releasing our internal framework as open-source software, was to share it with the community, hoping the quality would increase.

And it did! In 2O2O, Next Right Now was visited by people from 139 different countries, for a total of ~6k unique visitors!

Open-source takes time, it really does. But it's part of our core at Unly, our goal is to help students access higher education, and open-source is naturally on the way!

2020 statistics

Unsurprisingly, most visitors were from the United States.
What was more surprising through, is that India is ranked 2nd!
And France is 3rd, that was also a great surprise considering we're a French company ourselves!

Chrome was used by 80% of the developers reading the NRN documentation, Safari comes second (10%), then Firefox (6%) and Edge (3%). Nothing astounding here.

Bounce rate was around 50%, which isn't bad. There were more than 35k page views in total, with an average session duration of 2:36mn.

Those statistics are interesting and show us developers come back and spend even more time on the documentation, which is a great sign for conversion. That means people like what they see, and they come back for more.

And more, we've got!

2020 features

There have been some incredible features implemented in 2020, thanks to the community:

Trigger a GitHub Action workflow remotely (workflow dispatch), we've used this to trigger Vercel deployments from our Stacker app and from GitHub Actions UI itself!
A Vercel deployment webhook was added in December 2020, making it possible to get notified when a Vercel deployment is completed. We've used this to update our Airtable dataset automatically, works very great!
We've released our first GitHub Action less than 2 weeks ago (awaits for a Vercel deployment to be completed) and we're already working on a new one! (share GitHub Action variables between jobs) and it's being beta-tested at the moment!
We've recently updated the Next Right Now documentation, and explained in-depth all our built-in scripts and built-in utilities, among many other things.
Automated versioning, using the Git commit history.
Automated releasing, using GitHub Actions! (we've added quite a lot of automations this last month alone!)
Auto-aliasing of Vercel custom domains, for production but also preview! (which is a paid feature on Vercel, and quite an expensive one, too)

What about 2021?

We have many things planned for 2021, and we're very excited by the recent Vercel/Next.js announcements. 2021 looks promising already!

Also, we're gonna start a new big open-source project! It might just become the most flexible Chatbot out there ;)

How would you keep the same Python 2.7 app running for years to come?

Vadorequest — Mon, 13 Jul 2020 10:53:47 +0000

I've recently came across a new interesting challenge.

One of the app I'm working on is an old app written in 2016 using Python 2.7. It's basically a website/web platform where people can do stuff.

The platform is going to be discontinued soon, but needs to process data for the next 5-8 years nevertheless. The business context led to the decision of disabling new sign-ups and only allow existing users to sign in, so that they can access their data for years to come.

Not only the project is being discontinued, but the staff behind it too. Resources are scarce to say the least.

The goal now is to keep the platform in an operational condition, without making any changes to it. (or, as little as possible)

As you probably know, Python 2 is completely outdated and support is being dropped on many tools, such as pip which will drop support in January 2021, 6 months from now.

The challenge at hand here is to find a way to keep such a project in operational condition and keep it running for all those years to come.

But, I know it will eventually break. At some point, running pip install will not work anymore, whether due to pip itself or one of the thousands of the project's dependencies.

I've spent a good deal of time on this challenge already, and eventually chose to keep our current hosting provider for now (fully managed).

I also considered making a Docker instance so that the whole infrastructure gets "frozen", but even though I'm not sure the underlying provider (AWS, etc.) wouldn't deprecate such instances within 5-8 years of time and force us to move it to something different, which may lead to issues when reinstalling everything years later, with a different staff unfamiliar with the project.

Of course, rewriting the whole app is not an option, due to time/budget constraints. Also, the project being discontinued, it'd really not make any sense, financially wise.

So, I'm not asking for a magical solution. But I'm interested in similar experiences and feedback about what to do and not to do from peers who've known such a challenge. Would love to hear your story!

Next Right Now v2 - Play around with Next.js v9.4 using SSG/SSR, incremental builds, fallback builds, preview mode and more!

Vadorequest — Mon, 01 Jun 2020 21:06:08 +0000

Hello React lovers.

We recently released NRN v2, which features building web apps using Next.js framework (9.4) and GraphQL/GraphCMS. 🎉

Next Right Now (NRN) is meant to help you build production-grade projects using the Next.js framework. It can be used as a boilerplate to start a new project, or as an educational resource.

The v2 version brings the following features out of the box:

SSG: Static pages (per-page configuration SSG/SSR)
Preview mode: Preview dynamic content on “static” pages
Incremental rebuild: Rebuild part of your app incrementally (per-page configuration) to automatically keep static content up-to-date
Partial pre-build: Use fallback option to build your pages on-demand, and have them statically served afterwards
Full TS support
Hosted on Vercel
Advanced stages and secrets configuration
SaaS B2B advanced support (monorepo design)
I18n/Localisation
Automated deployments (CI/CD) using Github Actions
Monitoring, testing and analytics
Integrated documentation website using Jekyll and GitHub Pages

Demo: https://nrn-v2-mst-aptd-gcms-lcz-sty-c1.now.sh (play around with SSG/SSG, incremental builds, fallback builds, preview mode and more!)

Repo: https://github.com/UnlyEd/next-right-now

What's next?

NRN next preset will be an Airtable integration (instead of GraphCMS), to showcase how to consume a REST-ish API

NRN is officially recommended by React i18next for internationalising Next.js apps

Looking for a multi-tenants CMS

Vadorequest — Sun, 29 Mar 2020 21:51:35 +0000

I'm looking for a CMS/BackOffice/Admin site to help me manage my multiple B2B customers.

Our needs are:

Providing a backoffice to our customers, where each user can connect to its own tenant and access its tenant's data only.
The backoffice must be generated automatically from a data structure (db schema for instance)
An API must be generated automatically from the data structure (allows to consume the data from web apps, mobiles, etc.)
Ideally, this API would be a GraphQL server because that's what we use already.
Advanced permissions and roles for internal users, basically need to configure who can view which tables, or has update/delete permissions on which tables. It must be flexible and non-blocking for our business evolution/future needs
The backoffice needs to be flexible about UI components/views so that we can create our own workflows, views and components.
Theming capabilities of the backoffice, per tenant, would nice to have.

I've been looking for quite some time but none of my findings were satisfying.

Strapi is close but doesn't support anything related to multi tenancy, also permissions aren't as flexible as what we're looking for.

Any suggestion?

Next Right Now - Flexible production-grade boilerplate for building web apps (monorepo), with Next.js, Zeit and TypeScript

Vadorequest — Tue, 03 Mar 2020 14:27:17 +0000

Building a web app is hard. Building a production-grade app with a high Developer Experience is even harder. Configuring all must-needed frameworks and libraries is quite a challenge, and takes weeks, if not months of hard work.

Monitoring, analytics, reusable styles (css-in-js), graphql, i18n, testing, end-to-end testing, deployment pipeline (CI/CD), typescript, serverless... All these things are must-haves in 2020, and making them all work together is another challenge.

That's why we released https://github.com/UnlyEd/next-right-now, a boilerplate to help get started with all that. Though opinionated, it's flexible enough to adapt to your own needs. The goal is to get started with a production-grade setup in a couple of hours, instead of a couple of weeks (at the very least).

There are so many tools in the JS ecosystem now that one must have an opinion on what's good-enough and what isn't. It takes time to compare all css-in-js libraries, and that's just one tiny choice one must do to build isomorphic/universal web applications nowadays.

Next Right Now will help you get started quickly, and can also be used as a great learning resource, because we've documented about everything.

You want to build your own blog? An e-commerce website? Some showcase web app? NRN can help, from development to production.

And, it's flexible. Because you will not agree with all our opinions, and that's fine. Just get rid of what you don't like, as simple as that.

Let us know what you like/dislike!

What technologies can help building an interactive map of nodes, that may be linked to each other (JS)

Vadorequest — Sun, 19 Jan 2020 11:00:27 +0000

I'm looking for any tool (software, SaaS, open source libraries, etc.) that could help represent an interactive list of nodes that may be connected to each other, using javascript.

Here are a few requirements:

Renders in a browser environment (canvas, webGL, svg, etc.)
Compatible desktop and mobile
Interactive (detection of hovering, click event, etc.) on both nodes and connections
Interconnected (node can be linked to other(s), through connections)
Concept of proximity between nodes (some may be further away than other, depending on some criteria)
Allows for visual customisation of the nodes/connections representation (CSS, etc.), to replace a "dot" with an image, for instance

Here is a visual that shows what it could look like:

A few considerations:

I'm not looking for "the best" tool, but for any tool that matches those requirements.
I'm not sure if the term "map" is the best one, don't hesitate to propose a better term.
Optionally, a demo featuring the technology would be a great addition.

Airtable backups made simpler with AWS Lambda & S3!

Vadorequest — Sat, 11 Jan 2020 21:12:17 +0000

Today, we released as OSS our boilerplate project https://github.com/UnlyEd/airtable-backups-boilerplate which is meant to manage Airtable backups lifecycle for you.

See our announcement on the Airtable forum: https://community.airtable.com/t/unly-releases-an-open-source-software-for-airtable-managed-backups/26752

Share the OSS love!

[JS] Universal language detector

Vadorequest — Mon, 30 Dec 2019 03:27:13 +0000

We've been working with i18n (internationalization) for a few months, and we couldn't find any easy way of knowing what's the user's language that works both on the browser and on the server.

There are tons of libs out there, but none that are working universally. So, we decided to outsource our proprietary implementation and release it under MIT license.

Also, because we're fans of the Next.js framework, we've made an integration example with a demo available there:
https://universal-language-detector.now.sh/

https://github.com/UnlyEd/universal-language-detector

Did you get stuck too with a similar issue when implementing i18n? How did you sort it out? Does this lib help? Let us know! :)