Forem: Tomek Poniatowicz

URL - what is it?

Tomek Poniatowicz — Wed, 21 May 2025 06:48:39 +0000

Let's start with the basics. A URL (Uniform Resource Locator) is simply a unique address that allows you to find a particular page, file or resource on the web. By typing in a URL in your browser, you end up exactly where you want to go - whether it's to a shop homepage, a blog article or an image. Without URLs, the internet would be a pure chaos, because there would be no way to pinpoint where the content is.

What is a URL and what does it consist of?

If you're wondering: what is a URL and what does it look like, it's worth knowing that each URL is made up of several elements:

a protocol (usually https or http)
domain (e.g. twojastrona.pl)
path (e.g. /blog/what-to-address-url)
sometimes parameters (e.g. ?sort=desc)
excerpt (e.g. #section1)

An example URL might look like this:
https://yourpage.com/blog/adres-url?sort=desc#section1

URLs and SEO - why is it important?

OK, but what is a URL in the context of SEO? It turns out that the URL is one of the first elements that both search engines and users look at. A well-constructed URL helps Google understand what the page is about, and helps the user decide more quickly whether to click on a search result.

A friendly URL, i.e. one that is short, readable and contains keywords, can improve a page's visibility in Google. An example? If you run a blog about travel, it's better to use url: yourwebsite.co.uk/blog/japan-trip than yourwebsite.co.uk/blog/?id=1234.

Important rules for creating URLs for SEO

Before going into the specific rules, it is worth emphasising that proper URL design is the basis for effective SEO optimisation. A friendly and well-thought-out URL not only makes it easier for search engine robots to index your site, but also improves the user experience, increasing your chances of ranking higher in search results. Below, you will find key tips to help you create URLs that follow SEO best practices.

Use the https protocol - this builds trust and is a signal of quality to Google.
Use short, concise and logical paths.
Include keywords related to the content of the page, but don't overdo it.
Separate words with hyphens (not underscores).
Avoid Polish characters and special characters.
Don't change URLs for no reason - it can hurt SEO.

URL - what does it mean for the user?

A well-designed URL is not only a nod to search engines, but also a convenience for visitors. A clear url is easier to remember, copy and share. This makes users more likely to return to the site and recommend it to others.

Summary

URL is an online address through which anyone can reach a specific page or file. In the context of SEO, the URL is one of the key elements influencing SEO and user perception of a website. It is worth ensuring that it is clear, unique and complies with SEO best practices. A well thought-out url can be your ally in the fight for better positions in Google.

[Boost]

Tomek Poniatowicz — Tue, 13 May 2025 08:43:19 +0000

Tomek Poniatowicz for Aexol

May 12 '25

How To Reach Out On LinkedIn: Tips & Tricks

#marketing #beginners #tutorial

Comments 1

3 min read

How To Reach Out On LinkedIn: Tips & Tricks

Tomek Poniatowicz — Mon, 12 May 2025 14:38:28 +0000

LinkedIn is the world's largest professional networking platform, with over 900 million users worldwide. It serves as a space for professionals to connect, share content, and explore career opportunities. Many LinkedIn users are decision-makers, making it a powerful platform for marketing, recruiting, and sales outreach. Its focus on professional networking makes it ideal for B2B lead generation and relationship building.

Does LinkedIn outreach work?

Yes! LinkedIn outreach is highly effective when done correctly. It helps users expand their network, warm up leads, and build meaningful professional relationships. However, response rates typically range between 10% and 25%, so success depends heavily on personalization, clarity, and relevance of the message, as well as having a well-optimized LinkedIn profile that builds trust instantly.

How to reach out to people on LinkedIn

Reaching out on LinkedIn usually involves sending a connection request followed by direct messages once the connection is accepted. Connection requests allow up to 300 characters to craft a personalized message referencing mutual connections, shared groups, or relevant interests. After acceptance, you can send longer direct messages (up to 8,000 characters) to engage in more detailed conversations.

To make your LinkedIn outreach easier and more effective, consider using krul.app. KRUL is a tool that automates and personalizes LinkedIn outreach campaigns, helping you manage connection requests and follow-ups efficiently. It saves time while maintaining a personal touch, increasing your chances of successful engagements.

Important things to focus on in LinkedIn Outreach

Key focus areas for successful LinkedIn outreach include:

Profile Optimization: Have a professional photo, clear headline, and compelling summary to build trust before reaching out.
Personalization: Tailor your messages by mentioning mutual connections, shared groups, or specific content the recipient has posted.
Clear Purpose: Be upfront about why you’re reaching out without sounding overly salesy. Use polite, direct asks like suggesting a quick call or sharing valuable resources.
Conciseness: Keep messages short and to the point, as shorter messages tend to get higher reply rates.
Follow-up Strategy: Plan a series of messages that gradually build the relationship rather than pushing for immediate sales - don't be to pushy!

Examples of outreach templates

Having explored the theory, it’s time to take action! Below, you’ll find two practical LinkedIn outreach message templates designed to serve as valuable examples and inspiration for your own outreach efforts, of course, make sure to tweak it to adjuts your neeed. Here we go:

Template 1: Soft ask for a call

Hi [Name],Thanks for connecting! I’ve been following your work at [Company] and am impressed by [specific achievement]. I’d love to have a quick chat to explore how we might collaborate or share insights.

Template 2: Knowledge sharing

Hi [Name],I’ve helped businesses in [Industry] achieve [measurable results releveant to your prospect]. I’d love to connect and share a step-by-step guide on how you can achieve similar results.

Summary

LinkedIn is a powerful platform for professional networking and lead generation with a vast user base of decision-makers. Effective outreach relies on personalization, a strong profile, clear messaging, and respectful follow-ups. Tools like krul.app can help automate and personalize your outreach, saving time and improving results. Use thoughtful connection requests and direct message templates focused on building genuine relationships to increase your LinkedIn outreach success.

How To Reach Out On LinkedIn: Tips & Tricks https://krul.app/blog/how-to-reach-out-on-linkedin/

Tomek Poniatowicz — Mon, 12 May 2025 14:32:21 +0000

How to translate whole i18n folders?

Tomek Poniatowicz — Tue, 15 Oct 2024 14:42:13 +0000

Streamline Your Website Localization with DevTranslate’s New “Translate Folders” Feature

When it comes to making your website or application truly global, localization is a must. DevTranslate, a tool designed specifically for developers, has introduced an exciting “Translate Folders” feature that can significantly speed up and simplify the translation process. This powerful addition allows users to easily translate entire folders of files in just a few clicks, making it a game-changer for app and website localization.

In this post, we’ll explore how this new feature works, why it’s valuable, and how you can take full advantage of it to streamline your translation workflow.

What is the “Translate Folders” feature?

The “Translate Folders” feature in DevTranslate enables developers to upload and translate entire directories of resource files at once. This means you no longer need to translate individual files manually — instead, the tool handles the entire batch at once. Whether your project includes multiple JSON, XML, or ARB files, this feature supports bulk translation into 26 languages with seamless accuracy.

Key Benefits:

Bulk Translation: Save hours of work by translating entire folders in one go.
Time-Saving: Drastically reduce the time spent on localization by letting the tool handle multiple files simultaneously.
Consistency: By translating everything at once, you ensure that your translations are uniform across all languages and platforms.

How does it work?

Using the “Translate Folders” feature is incredibly simple:

Upload your folder: Drag and drop your folder containing files such as .json, .xml, .arb, or .strings.
Select files that need to be translated: If the folder contains files that don't need translation, select only those that should be translated.
Select input & output languages: Choose the source language of your content and the languages you want the files to be translated into.
Click translate: DevTranslate will process your folder in a matter of minutes.
Download Translated Files: Once the translations are complete, you can download the fully localized folder and integrate it back into your project.

Why it’s so cool?

For developers working on large-scale apps or websites with regular updates, this feature is a game-changer. Instead of manually translating new content every time an update is rolled out, DevTranslate automates the process. This is especially beneficial for teams managing multi-language websites or apps where updates happen frequently, ensuring that the translated content is always up-to-date and consistent across different languages.

Here’s why folder translations stand out:

Effortless integration: Upload your folder, select the languages, and let DevTranslate do the rest.
Avoid manual errors: Automating translation eliminates the risk of human error, ensuring accuracy and consistency.
Simple to use: Whether you need to translate one file or a hundred, DevTranslate’s folder translation scales effortlessly.

Translate your website with ease

If you’re looking to localize your website or app with minimal hassle, the “Translate Folders” feature is your best bet. By leveraging this feature, you can streamline your workflow, ensure consistency, and reduce the time spent on localization. Best of all, you can maintain a localized experience for users across the globe with just a few clicks.

Don’t miss out on reaching new audiences — try DevTranslate today and take your localization efforts to the next level.

Ready to Get Started?

The DevTranslate “Translate Folders” feature is designed to make your website or app localization easier, faster, and more efficient. Whether you’re an individual developer or part of a larger team, this feature helps you seamlessly scale your app to new markets.

Optimize your localization strategy by giving the Translate Folders feature a try today! Visit DevTranslate to get started.

How to send lead emails from your website form?

Tomek Poniatowicz — Mon, 12 Aug 2024 08:45:26 +0000

Web forms reign supreme as a lead generation tool for small businesses. Their popularity stems from several key advantages, one in particular that is overwhelmingly emphasized by all sources - the ease with which they can be integrated into any website. It sounds sensible, but is that where the work with forms ends? Certainly not, on the contrary, this is just the beginning and the hardest part is yet to come.

I have added form to my website, now what?

So you've added a form to your site and are hoping that momentarily leads will start flowing to .... just where? To get responses from online forms you should use two approaches:

interfacing with the form of one of the many CRM platforms available on the market.
send them as an email

Like everything, each of these has its pros and cons.

Pros and cons

Let's start with CRM. Undoubtedly, it is a convenient way to receive content from online forms, allowing you to define and build a sales process, but CRMs can be very expensive which is often a no go for small companies. Another downside is that it's another tool you have to add to your daily routine and monitor so you don't miss out on new leads.

And how about sending emails? The plus side is that they go straight to your mailbox, so the place you check regularly and the chance of missing them is really low. So far, the biggest drawback has been the difficulty of integration, as setting this up correctly requires integration on the frontend side, but also playing with SMTP server, its correct configuration so as not to fall into blacklists etc. On the other hand, this is no longer a problem because ...

The solution - Mailik.dev

Mailik is a small and easy to use library that allows you to send emails directly from the code of your site with minimal effort (see the documentation). Basically, all you need to do is sign up for a free account, create a project for which Mailik automatically generates a unique key and you point it at your implementation (see example below) ... and you're done.

import Mailik from "@mailik/sdk";

type MailInputType = { body: string; subject: string; replyTo: string };

const handleSubmit = (values: MailInputType) => {
  const res = await Mailik(YOURS_API_KEY).send({
    replyTo: data.email,
    body:`
          Name: ${data.name},
          Message: ${data.message},
          Phone:${data.phone}
        `,
    subject: "Mail subject",
    });
  }

Replies from your website's forms will go straight to the designated mailbox and you will be able to respond to your potential customers (as long as you would collect their emails :)) and convert them into leads for your company!

Final words

These forms serve as a critical point of contact, converting casual browsers into potential customers or subscribers with minimal friction, which is why every online business should make every effort to make this channel of lead acquisition work flawlessly - Mailik.dev has just made it very easy!

Apple DMA changes - for better or for worse?

Tomek Poniatowicz — Fri, 26 Jan 2024 10:41:32 +0000

Yesterday (25 Jan 2024) Apple announced some major changes to iOS, Safari, and the App Store operating model that would impact developers' apps in the European Union. The motivation for the changes is to comply with the Digital Markets Act (DMA) that came into force in Nov 2022. Let's have a look at the most interesting ones, or if you want to see the full list of changes go to Apple's official announcement.

What's new for iOS

For iOS, Safari and App Store to become DMA compliant Apple has been forced to significantly loosen many of its previous restrictive operating rules which will result in:

New framework and APIs for browser engines — which will allow developers to use browser engines, other than the default iOS WebKit, for browser apps and apps with in-app browsing, which is a huge impact on developers, as it should give them some more options when dealing with WebView.
Interoperability request form — through which developers can apply to unlock additional iPhone, iOS hardware and software functionalities which should lead to some cool new products see daylight

A lot of you might say:

"Hey, what about the alternative app marketplace deregulations?"

so it looks like we should indeed get some new APIs & tools for publishing, downloading & even updating apps from alternative marketplaces, but this comes with even more safeguards (regulations?) in the form of:

Notarization for iOS apps
App installation sheets
Authorization for marketplace developers
Additional malware protections

which is hardly surprising as this could pose a risk for iPhone end users. I honestly believe that the majority of users and app download traffic will remain in the App Store anyway. It's a tidy, familiar & trustworthy environment, so nothing should change until a high-trust alternative emerges.

What's new for the App Store

Changes to the App Store terms cause, to put it mildly, mixed feelings. So we're getting a tool which lets us estimate fees, better understand metrics associated with Apple's new business terms for apps in the EU (which will be covered in a minute) & a bunch of new really nice deregulations like the ability to:

use 3rd party payment service providers - we're finally getting a way to process payments for digital goods and services directly from our iOS app (no additional fee to Apple),
process payments via link-out - users can finally complete a transaction for digital goods and services on developer's external website (no additional fee to Apple),

and there is one but. This leads us to...

New Business Terms for Apps in the EU

Let's start with the fact that we can choose to accept these new business terms or stay on Apple's existing terms, but of course, the previously mentioned deregulations are only included in the new business terms.

Now let's see what's inside. It starts nicely with two eye-catchers in the form of:

Reduced commission — iOS apps on the App Store will pay a reduced commission of either 10 percent (for the vast majority of developers, and subscriptions following their first year) or 17 percent on transactions for digital goods and services.
Payment processing fee — iOS apps on the App Store can use the App Store's payment processing for an additional 3 percent fee. Developers can use a payment service provider within their app or link users to their website to process payments for no additional fee to Apple.

but then we're getting hit with:

Core Technology Fee — iOS apps distributed from the App Store and/or an alternative app marketplace will pay €0.50 for each first annual install per year over a 1 million threshold,

since we're getting a cool new tool to "estimate fees, better understand metrics associated with Apple" let's do the math. As it was put nicely by Nikita Bier on his Twitter (@nikitabier) an app that would work & sell digital goods under new terms that generate 10 000 000 installs per year and is forecast to reach 10 000 000$ in sales can expect to pay a whooping 500 000$ in monthly fees. OK, the yearly APRU of 1$ is a bit higher (or a lot higher?) than the sector average, but as you can see in the breakdown below most of the fee is coming from the so-called "Technology Fee" which is tied to your install volume.

// Detect dark theme var iframe = document.getElementById('tweet-1750592825060921353-937'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1750592825060921353&theme=dark" }

Conclusion

Considering all the above are we really getting a batch of deregulations or just DMA-compliant illusion of an alternative solution which in comparison with the current one comes out so poorly that few will want to use it? Apple boldly estimates that the new business terms would reduce or maintain the current level of fees paid to Apple for 99% of developers and that less than 1% would need to pay a Core Technology Fee on their EU apps. Let's wait and see.

About Aexol

Need help with software development? At Aexol, we develop mobile and web applications helping our clients grow. We are TypeScript and GraphQL focued company.

GraphQL benefits and why you should adopt it in 2024

Tomek Poniatowicz — Fri, 19 Jan 2024 17:10:51 +0000

The digital world is changing faster than ever. In an environment where new frameworks, technologies and tools are coming out almost every minute, scalability is not just an empty phrase, but the bare minimum to allow the development of an IT project. In this busy and ever-changing landscape, GraphQL architecture is steadily gaining popularity. Why? Thanks to its flexibility and precise data fetching mechanism. However as applications grow in scale and gain more users, the efficient scaling of GraphQL APIs becomes not only important, but actually crucial to ensure consistent performance and reliability.

In this short blog, we'll explore a variety of practices that allow you to smoothly adapt to the rapidly changing digital environment. From leveraging caching mechanisms and query optimization, to exploring advanced tools that allow you to expand your infrastructure as your applications grow - all to show how important it is to ensure the consistency, performance and reliability of your GraphQL API.

Let's start with the topic closest to my heart, due to the fact that our tool is used mainly (but not only) for designing GraphQL schemas.

Efficiently designed schema is the key

The foundation of a performant GraphQL API lies in its schema design*. When thinking of your schema there are a lot of things you need to cover (or at least be aware of), but to fully enjoy the DX and the speed of working with GraphQL lest start with data fetching. The main points I want to cover here are:

over-fetching & under-fetching: which is handled out of the box with the GraphQL queries system which enables retrieving only the required data, preventing unnecessary data retrieval or messing up your network bandwidth.

and its biggest nightmare which is:

deep nesting: when planing your GraphQL schema avoid going to deep or your will bury yourself with nested queries that can lead to performance bottlenecks and may nullify the highly optimized fetching system which you're getting for free in GraphQL! Keeping query depth shallow will let you enjoy faster query execution and reduce logic complexity for your team.

*if following the schema first path; schema first is our preferred approach here at GraphQL Editor & the entire blog post may be seen as biased in favor of schema first

Data fetching, batching & caching

When we talk about making things run faster, getting data quickly is super important. Using some basic data caching & batching techniques you can really amp up how well your API works, giving it a serious speed boost without much hassle.

use DataLoader: DataLoader is a utility that can be used as part of an application's data fetching layer to provide a simplistic and consistent API for different remote data sources (web services, databases etc.) through batching and caching.
implement layered caching: Using caching in different places, like on the client's side, the server's side or CDN (if used) can really help as it stops things from being fetched over and over and makes the general server response time way faster.
pick right cache eviction policy: Once again caching is critical for any high-performance system so make sure to use a cache eviction policy (when things which are not needed anymore are kicked out of the cache) that fits your project. Keep in mind you need to figure out how to keep all the different caches in sync so they have the same information. This way, you make sure everything stays up-to-date and works smoothly.
batch your data: Merge multiple data requests into a single query to minimize round trips and improve efficiency, leveraging GraphQL's ability to fetch multiple resources in a single request.

Monitoring, optimization, load balancing & horizontal scaling

Continuous monitoring and optimization are required to keep your app running fast and smooth. Good monitoring tools, load balancing and horizontal scaling are your pals when it comes to handling peak traffic... and it also helps to retain customers as bad latency can wreck customer experience even for the best designed, shiny app. Keep your eyes on:

profiling & monitoring: regularly check and analyze query execution times using monitoring tools to pinpoint and address performance issues effectively.
resolver optimization: always aim to improve the efficiency of resolver functions to boost query performance. Don't wait and try to immediately address any issues with slow-performing queries for better overall system responsiveness.
load balancing: most cloud infrastructures have a load balancing feature available out of the box, but if you're working on your own infrastructure (which is becoming a new trend after the "serverless hype" era), make every effort to evenly distribute incoming requests across multiple servers to prevent overload, ensuring a balanced workload and maintaining system responsiveness.
horizontal scaling: scale your application by adding more server instances to handle increased demands and manage them efficiently through tools which help achieve seamless orchestration like K8s the open-source system for automating deployment, scaling, and management of containerized applications.

Don't rush with GraphQL adoption

As always, the old saying that haste makes waste rings true. Rather than rush, take your time to give yourself and your users peace of mind. Transitioning from REST to GraphQL is one thing, overcoming obstacles that you didn't foresee at the beginning (let's not kid ourselves, there is no such thing as smooth transition and if there's even a small chance that something might go wrong you can be sure it will) so be prepared to handle one of the greatest scalability challenges which is:

backward compatibility: with GraphQL you get backward compatibility out of the box and new fields can be added to the schema without impacting existing queries. This is in contrast to REST, where changes to the API may disrupt existing clients. So when you finally decide to transition from REST to GraphQL remember to ensure backward compatibility.

Teamwork makes the dream work - collaborate!

Having effective communication and maintaining detailed documentation - these are the two keys for ensuring your team enjoys effective collaboration and is working effectively. Find a platform that can streamline and simplify communication over your schema (the most important piece of your GraphQL project) leave no room for understatement as the key to your project's success is:

teamwork: GraphQL is all about collaboration between frontend and backend teams, helping develop a common understanding and an efficient query optimization approach. This is where our GraphQL Editor can help increase the work effectiveness of teams through such features as Live Collaboration that allows multiple team members to work on a GraphQL schema & in general through its visual features that provide a better picture of the schema overall.

From niche to mainstream

It's been 8 years since Facebook released GraphQL and the days when it was some fresh, niche technology are long gone. By now it has moved way past the hype phase, and has easily maintained its status as the main competitor to the steadily declining REST over the past few years. Hardly surprising taking into account the various GraphQL benefits mentioned above, especially with the schema-first approach I've recommended earlier. So while rushing into adoption isn't a good idea, considering it definitely is!

GraphQL AI Platform for developers

Tomek Poniatowicz — Fri, 10 Nov 2023 15:07:36 +0000

Hey there! We're building a developer-oriented AI tool suite called - GraphQL AI

What is GraphQL AI?

Basically we're creating a GraphQL-based playground where you can train your own chatbot instances, link them into a network, generate images using various models, and do other cool stuff faster than you can say "Hello, World!".

We're on the brink of release (hopefully) and have created a waitlist you can join to get notified when the tool is ready.

How much does it cost?

NOTHING - it's currently FREE. I guess we would need to think about monetization at some point but definitely not in the nearest future.

How does it work?

We provide the infrastructure to build things but you need to use your own OpenAI and Replicate keys. OpenAI's throwing in a free ~20$ worth of API credit for new users so you can basically play with it 100% free.

Check out the landing page for a sneak peek: GraphQLAI

Direct waitlist link here: Join the Waitlist

See you on the flip side of GraphQL innovation!

Conditional rendering in React

Tomek Poniatowicz — Sun, 05 Nov 2023 16:46:05 +0000

I recently saw some posts and comments about conditional rendering in React and to my surprise some of them stated && was outdated and should be dropped in favor of using if/else, : ? and || conditions. It struck me as odd as from what (admittedly little) I have learned so far AND is fine and in some cases simply more straightforward. Especially when compared with sticking nulls everywhere just to avoid using it. Far be it from me to criticize anyone but I decided this would be a good idea to elaborate more on conditional rendering in React.

if/else and ternary operator :?

This is most likely the first type of conditional you’ve learned, honestly I didn't even know it was called a ternary operator until writing this as I’ve heard our devs simply call it an ‘if’ or ‘conditional’. Both are very straightforward and work pretty much the same although with a slightly different syntax:

PowerLevel  > 9000 
? console.log(‘Its over 9000!!!’) 
: console.log(PowerLevel)

if (PowerLevel > 9000)
{console.log(‘Its over 9000!!!’)}
else
{console.log(PowerLevel)}

Both of these will do exactly the same thing but the syntax is slightly different. For a simple thing like this the ternary operator is just more succinct and makes more sense to use. It's obviously down to personal preference but from what I’ve heard from devs the rule of thumb is:

use :? for smaller things that can fit in one line or two (eg. for registered users show a button with “Log in” and for unregistered show it with “Register”)
use if/else statements for executing bigger segments of code (like say a different navbar for desktop and mobile versions of a website)

Just to give you a real example this is a simple code snippet from our language switcher:

push(pathname.replace('[locale]', newLang === 'en' ? '' : newLang));

It's pretty simple - when the user selects a language from the dropdown it pushes the user to the selected language version of the page adding the locale tag to the url address, but omitting it if it's the default language ie. English. (sidenote here: this is actually very important for SEO as I’ve had multiple issues with language selectors adding a default locale tag to the url which caused example.com and example.com/en to be flagged as duplicate pages)

While using ternary and if/else is the go-to it can be overused because of that, as sometimes other conditionals make more sense. Take this simple snippet for a metaDescription meta tag in my custom helmet - it uses the provided metaDescription if there is one and a fallback value if it is not provided:

<meta
  name="description"
  content={metaDescription ? metaDescription : defaultDescription}
/>

OR (||) condition

While that works fine I’ve actually started using OR conditions for cases like this since they are simpler and quicker to write. From my experience this is used way too little since you get tons of situations like this (especially when dealing with websites) where you just need one value and a default fallback just in case. Following the above metaDescription example we can just use this to get the exact same result:

<meta name="description" 
content={metaDescription || defaultDescription} />

It will simply always use a metaDescription if one is provided, and fallback to the default one if it is not, which is perfect for use cases like this. Yes you can use multiple || and it will simply always render the first one that is true, but I think that’s overusing it since you can't specify different conditions for each one anyway and at that point using a ternary condition or if/else makes more sense anyway. You can also use || with a null for an element you only want to render under certain conditions, but for that case && actually makes more sense in my opinion.

AND (&&) condition

Like I said before I have seen some claims && is outdated, which surprised me since I consider it by far the cleanest to use when I want to render an element only under certain conditions. It works the simplest of all of the ones I mentioned here as it just does nothing if the condition is not fulfilled. Yeah you can do that with the others - just use a null and you’ll likely get the same result - though writing nulls everywhere just for the sake of avoiding && seems pointless.

Sure you can get a displayed 0 error like the one on the screen below:

Obviously if you’re afraid you might get one for something like products.length on your ecommerce store it's also pointless to force yourself to use && just for the sake of it - it's way better to go with what you feel more comfortable with. That said, this particular error was solved by simply using !! to force a boolean representation and the && was left untouched - which goes to show once again that all this comes down to what you're most comfortable using.

For me I can say that on the SEO side I’ve fixed enough bugs and issues where someone forgot to add a null and I had off-screen or hidden elements picked up by crawlers. If you like the seo guys in your workplace you can be nice and save them an hour or so which they might otherwise spend looking for a mobile langSwitcher with a 404 link which was hidden somewhere on the desktop version of the page. So for a simple component that you want rendered only if a certain condition is fulfilled && is still perfectly fine in my opinion. Here's an example case of where I use it in my custom helmet element:

{
  LocalizedPage && (
    <>
      {hrefLangs.map((lang) => (
        <link
          key={lang}
          rel="alternate"
          hrefLang={lang}
          href={`https://example.com/${lang}${location}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang={defaultLang}
        href={`https://example.com${location}`}
      />
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${location}`}
      />
    </>
  );
}

As you can see that is even simpler than the others - only render this code if the page is localized. I don't have to specify the outcome for false or a fallback null value - I just say this is solely for that condition and that's it. This is a simple way of ensuring I have alternate links included in the head for pages which are translated into other languages, while making sure they won't appear in the dom for those which aren't translated (like say blogposts) which would be flagged as a SEO error. I think it's also a good approach to keep things as simple as possible when it comes to seo so if I go into someone’s frontend code to add this little element they figure out exactly what this is intended for at a glance.

Obviously if you’re comfortable with using if/else everywhere and that works for you there's no reason to force yourself to use something else, even if it can make more sense in certain situations. But as you can see in using OR or AND can be handier so it's perfectly fine to use those as well, they are in no means outdated or wrong if used correctly.

Easy Vue internationalization - guide to the Vue I18n plugin

Tomek Poniatowicz — Thu, 26 Oct 2023 13:56:18 +0000

In today's globalized world, it's crucial for web developers to create applications that can be easily localized for users from different regions and cultures. Vue.js is a popular JavaScript framework which provides a powerful internationalization (i18n) plugin called Vue I18n. In this comprehensive guide, we will do a step-by-step exploration of the process of internationalizing a Vue app using the Vue I18n plugin. Whether you're a seasoned Vue developer or just getting started, this guide will get you up to speed on how to create multi-language applications with ease.

What is Vue I18n?

Vue I18n is a localization library for Vue.js that helps developers easily handle application translations. It provides a simple and flexible API to integrate translations into Vue components, which makes creating multi-language apps almost effortless. With Vue I18n, you can define translation messages in different languages and easily switch between them based on the user's locale. It also supports multiple advanced features like dynamic translations or pluralization which makes it a truly comprehensive solution for Vue internationalization.

Getting Started

Before we get to Vue internationalization, we first need to include the necessary scripts in our HTML file. You can include Vue and Vue I18n using either a script tag or a module bundler like Webpack. Here's an example of including the scripts via a script tag:

<script src="https://unpkg.com/vue@3"></script>
<script src="https://unpkg.com/vue-i18n@9"></script>

Now that the scripts are included, we can go ahead and create a Vue instance and configure the Vue I18n plugin. In the following example, we'll define translated messages for English and Japanese:

const messages = {
  en: {
    message: {
      hello: 'Hello, world!'
    }
  },
  ja: {
    message: {
      hello: 'こんにちは、世界！'
    }
  }
};

const i18n = VueI18n.createI18n({
  locale: 'ja',
  fallbackLocale: 'en',
  messages
});

const app = Vue.createApp({
  // Vue app options
});

app.use(i18n);
app.mount('#app');

In this code snippet, we've defined the translated messages in the messages object, with the keys representing the locales (e.g., en for English and ja for Japanese). We then created an instance of Vue I18n using createI18n and passed in the locale, fallback locale, and messages. Finally, we installed the i18n instance on the Vue app using app.use(i18n) and mounted the app on the DOM element with the ID app. This sets up the Vue app to be aware of the i18n instance and enables the translation functionality.

Translating Text in Templates

Once the setup is done, we can start working on Vue internationalization, first let's go to our templates. Vue I18n injects the $t translation API into each component, letting us easily access translated messages. Here's an example of how to use the $t API in a template:

<div id="app">
  <p>{{ $t("message.hello") }}</p>
</div>

In this example, we use the $t API to translate the message with the key "message.hello". The translation is determined automatically based on the current locale set in the Vue I18n instance.

Dynamic Translations

Vue internationalization also supports dynamic translations, enabling passing variables to translated messages. This is useful when you need to include dynamic content in your translations, such as usernames or numbers. Here's an example:

<div id="app">
  <p>{{ $t("message.greeting", { name: userName }) }}</p>
</div>

In this example, we have a dynamic message key "message.greeting" and pass an object with a name property to the $t API. The value of userName will be dynamically inserted into the translated message.

Pluralization

Pluralization is a common requirement in internationalization, and Vue internationalization provides built-in support for handling plural forms in translations. You can define different translations for singular and plural forms of a message and let the Vue I18n plugin automatically select the appropriate translation based on the quantity. Here's an example:

const messages = {
  en: {
    message: {
      apple: 'one apple | {count} apples'
    }
  },
  ja: {
    message: {
      apple: 'りんご一つ | りんご{count}個'
    }
  }
};

In this example, we define translations for the key "message.apple". The English translation has two forms: "one apple" for singular and "{count} apples" for plural. The Japanese translation also has two forms: "りんご一つ" for singular and "りんご{count}個" for plural. Vue I18n will automatically select the appropriate translation based on the value of count.

Using the Composition API

In addition to the options-based API shown in the previous examples, Vue I18n also has a feature called the Composition API, which provides a more flexible and powerful way to handle translations. To use the Composition API, we need to call the useI18n function in our Vue setup function. Here's an example:

import { useI18n } from 'vue-i18n';

export default {
  setup() {
    const { t, locale } = useI18n();

    return {
      t,
      locale
    };
  }
};

In this example, we import the useI18n function from vue-i18n and call it in the setup function of a Vue component. This gives us access to the t translation function and the locale property, which can then be used in the template or other parts of the component.

Advanced Features with Vue I18n

Vue I18n provides a range of advanced features to handle complex translation requirements. Some of the notable features include:

Custom Formatting: You can define custom formatters to format translated values based on your specific requirements.
Fallback Strategies: Vue internationalization allows you to define fallback strategies for missing translations, ensuring a smooth user experience even when translations are not available.
Number and Date Formatting: Vue I18n provides built-in support for formatting numbers and dates according to the user's locale.
Pluralization Rules: You can customize the pluralization rules for different languages, allowing you to handle complex plural forms.

Bonus - How to easily translate your i18n files

To learn more about Vue internationalization and its features, refer to the official documentation of Vue.js. Additionally, you can use tools like DevTranslate to automate the translation process and manage your Vue files efficiently.

Conclusion

In this comprehensive guide, we explored the process of Vue internationalization using the Vue I18n plugin. We learned how to set up the whole process, translate text in templates, handle dynamic translations and pluralization, and use advanced features provided by the plugin. With Vue I18n, developers can easily create multi-language apps that cater to a global audience. By following the steps outlined in this guide and leveraging the power of Vue internationalization, you can ensure a seamless localization experience for your Vue projects.

I18next translations inside maps & React dynamic import

Tomek Poniatowicz — Thu, 19 Oct 2023 09:32:33 +0000

Recently while browsing through one of our projects I found some atrocious piece of code I wrote a few months back. As ugly as it looks I think it can serve as a decent example of how much you can progress in a short time, even as a ‘copywriter-turned-not-really-a-dev’ like myself, and also how much you can do wrong in just one simple component.

While the code here serves as an example for the sake of the blogpost, it is an actual piece of my code from one of our websites. It's a simple component with four tiles with an image, some text and icons that illustrate the features of one of our applications. In case you're wondering why fixing it matters, I can tell you that if there's one thing that impacts SEO - it's poorly written code. It can worsen performance causing our website to work too slow and incur something Google calls Cumulative Layout Shift. It's basically a measurement of how much crawlers see your website's layout change as components or elements are loading in, which may happen if your code is bloated. Google considers that bad for user experience and can penalize your website's positioning for it. Aside from that obviously fixing bad code just for the sake of it is reason enough (especially if you don't want to get yelled at during code review). So here's the code for the component:

import { useTranslation } from 'next-i18next';
import { AutomationIcon, FastIcon, ProcessorIcon, AccurateIcon } from '@/assets';

export const FeaturesSection = () => {
    const { t } = useTranslation('landing');
    return (
        <FeatureSectionWrapper>
            <FeatureText>
                <h2 className="header" dangerouslySetInnerHTML={{ __html: t('features.header') }} />
                <div className="desc">{t('features.description')}</div>
                <ul>
                    <li>
                        <div>
                            <AccurateIcon />
                            {t('features.features.accurate')}
                        </div>
                        <p>{t('features.features.accurateText')}</p>
                    </li>
                    <li>
                        <div>
                            <FastIcon />
                            {t('features.features.fast')}
                        </div>
                        <p>{t('features.features.fastText')}</p>
                    </li>
                    <li>
                        <div>
                            <ProcessorIcon />
                            {t('features.features.ai')}
                        </div>
                        <p>{t('features.features.aiText')}</p>
                    </li>
                    <li>
                        <div>
                            <AutomationIcon />
                            {t('features.features.automated')}
                        </div>
                        <p>{t('features.features.automatedText')}</p>
                    </li>
                </ul>
            </FeatureText>
            <FeatureImg
                src="/images/results.png"
                alt="feature image"
            />
        </FeatureSectionWrapper>
    );
};

As you can see even though I had some basic understanding of html and the useTranslation hook, but I made a mess of it because I didn't do any mapping and just wrote out every segment of the component as a list item. The component is rather simple, it has two columns - one is an image and the other has a header, description and four smaller tiles with titles, descriptions and icons. First we need to properly map the translated text and for that we have to restructure the json file with the translations:

"featuresSection": {
        "header": "lorem ipsum header",
        "description": "lorem ipsum desc",
        "features": {
            "fast": {
                "name": "Fast",
                "text": "lorem ipsum dolor",
                "icon": "FastIcon"
            },
            "accurate": {
                "name": "Accurate",
                "text": "lorem ipsum dolor",
                "icon": "AccurateIcon"
            },
            "ai": {
                "name": "AI powered",
                "text": "lorem ipsum dolor",
                "icon": "ProcessorIcon"
            },
            "automated": {
                "name": "Fully automated",
                "text": "lorem ipsum dolor",
                "icon": "AutomationIcon"
            }
        }
    },

Now that we have everything neatly organized in our json files it's time to map it using the i18next useTranslation hook. Lets use a const for the section of the landing json file we're using so that we can then access it via just curly braces like in the h2 and desc div here:

import { useTranslation } from 'next-i18next';

const { t } = useTranslation('landing');
const featSection = t('featuresSection');
<h2 className="header" dangerouslySetInnerHTML={{ __html: featSection.header }} />
<div className="desc">{featSection.description}</div>

Alternatively you can use the built-in i18next attribute KeyPrefix. I think this works the same way regardless (unless there's some key difference I’m unaware of) but I just like using the const as that way I can access every translation string by just calling the const name in curly braces {featSection.whatever} instead of doing {t(‘whatever’)} but that’s just personal preference and you can do it like this as well:

const { t } = useTranslation('landing', {keyPrefix: 'featuresSection'});
<h2 className="header" dangerouslySetInnerHTML={{ __html: t('header') }} />
<div className="desc">{t('description')}</div>

With that done let's change the html code for the list items. We can simplify it since all the list items are structured the same way:

<li key={key}>
  <div>
    <IconComponent />
    {name}
  </div>
  <p>{text}</p>
</li>

Now for the whole list we still need to map these elements, at first I went with this:

const iconComponents = {
        AutomationIcon,
        FastIcon,
        ProcessorIcon,
        AccurateIcon,
};
<ul>
    {Object.keys(featSection.features).map((key) => {
        const { icon, name, text } =
            featSection.features[key as keyof typeof featSection.features]; const
                IconComponent = iconComponents[icon as keyof typeof iconComponents];
        return (
            <li key="{key}">
                <div>
                    <IconComponent />
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>

While that worked it required an extra const and a somewhat hacky workaround for a TypeScript type error via as keyof typeof and pointing it to featSection.features. We can definitely do better! In general there’s three methods of mapping objects: keys, values and entries (which contain both keys and values). As you can see at first I went with keys, but using values makes more sense since that way TypeScript can infer the type values and we can just use idx which will also let it identify the key values. That approach lets us get rid of the const and simplify the code again:

const iconComponents = {
        AutomationIcon,
        FastIcon,
        ProcessorIcon,
        AccurateIcon,
};
<ul>
    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
        const IconComponent = iconComponents[icon as keyof typeof iconComponents];
        return (
            <li key={idx}>
                <div>
                    <IconComponent />
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>

That's nice and simple but as you can see I'm still defining the icon types and values via an extra const and the hacky as keyof typeof workaround. To get rid of that we can use React's dynamic imports. Since the json file already defines what icon should be in each component we can use that to import the icons dynamically. So now instead of using import for each icon individually we can import them dynamically by using this:

import * as Icons from '@/assets';
<ul>
    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
        return (
            <li key={idx}>
                <div>
                    {Icons[icon as keyof typeof Icons]()}
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>

Now we can even use different icons for different language versions if we want to, by simply specifying their names in that language json file. Let's look at the whole component:

import { useTranslation } from 'next-i18next';
import * as Icons from '@/assets';

export const FeaturesSection = () => {
    const { t } = useTranslation('landing');
    return (
        <FeatureSectionWrapper>
            <FeatureText>
                <h2 className="header" dangerouslySetInnerHTML={{ __html: t('features.header') }} />
                <div className="desc">{t('features.description')}</div>
                <ul>
                    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
                        return (
                            <li key={idx}>
                                <div>
                                    {Icons[icon as keyof typeof Icons]()}
                                    {name}
                                </div>
                                <p>{text}</p>
                            </li>
                        );
                    })}
                </ul>
            </FeatureText>
            <FeatureImg
                src="/images/results.png"
                alt="feature image"
            />
        </FeatureSectionWrapper>
    );
};

That's a lot cleaner and less painful to look at, and it only took a couple simple changes. Obviously it's a reach to call this a refactor or really anything but a small fix, but going over earlier mistakes makes things easier to remember (at least for me). It's also a small step towards writing cleaner and simpler code which is a good thing to keep in mind. It's also the best route to take especially in regards to SEO where better safe than sorry is the only correct approach. You can be sure that it's a whole lot easier than figuring out which piece of code on your website is causing the dreaded layout shifts Google has flagged you for.