21 ms·

Lessons From Linguistics: i18n Best Practices for Front-End Developers

188 points by open-source-ux 3y ago

Etheryte 3y ago
In general a good short rule of thumb is to always always _always_ write out the full sentence you want to translate and use the tooling to interpolate everything you want to put in it. That way the translator always sees the full context and you make it harder (although not impossible) for yourself to shoot yourself in the foot. Another recommendation I would add is to use two meta locales in development in addition to whatever you need to support otherwise: id and pseudo. The id locale should be an identity function so you (and the translator and everyone else) can open up a page and see what keys are used on that page. The pseudo locale should be either random or pseudorandom text and is good for both ensuring you haven't accidentally left something hardcoded as well as checking how your layout plays with different length strings. These ideas alone will get you most of the way most of the time, and they have the added benefit that they're straightforward to teach to juniors.
- worklaptopacct 3y ago
  Common translation tools would benefit from the ability to input some domain information. Typing in an entire sentence is a sensible start, but oftentimes a lone sentence does not carry enough context. Example: in my language, the term "fresh water" translates to "fresh water" or "sweet water". "Sweet water" is the opposite of saltwater, while "fresh water" would only be used in a context like "water in a tank has been replaced". The translations in Cities: Skylines use the literal translation and this has always irked me; if the translator accepted "plumbing" as a context, it would have produced a correct translation.
  - Etheryte 3y ago
    Most common translation tools already support this. From GNU gettext where it's called context [0], to FormatJS where it's called a description [1], all translation tools worth their salt support providing additional information about the usage. The problem is generally not on the tooling side but on the awareness side, if the person implementing the feature only speaks one language it's easy to overlook issues that wouldn't occur in their native language. [0] https://www.gnu.org/software/gettext/manual/gettext.html#Contexts https://www.gnu.org/software/gettext/manual/gettext.html#Con... [1] https://formatjs.io/docs/intl/#message-descriptor https://formatjs.io/docs/intl/#message-descriptor
    - holoduke 3y ago
      If you can tell me how to provide context in the google translation api i would be very happy. Dont think it exists. Only in the web version.
  - Kerrick 3y ago
    For what it's worth, the term "fresh water" has each of those separate connotations in American English too, and it can be just as context-dependent. Both "These fish belong in fresh water, not salt water" and "I put fresh water in the ice trays because the old stuff was stale" are valid contextually and linguistically.
    - fjkdlsjflkds 3y ago
      Yes, but it does not necessarily have those two connotations in other languages (which is the issue here). In Portuguese, if you want to say "fresh water" (as in, "low-salinity water"), you use the term "sweet water", rather than "fresh water" ("fresh water" can only be interpreted either as "cold water" or "non-stale water", but never as "low-salinity water").
  - p3rls 3y ago
    In English we have the term potable to designate drinkable water, which comes from an old PIEish verb meaning to drink that no one uses anymore and so it's often confused with "pottable" i.e., to be put into a pot, as in a game of pool (a non-aquatic table sport fyi)
    - dejj 3y ago
      What does PIEish mean?
      - mablopoule 3y ago
        Not op, but I think it stands for Proto-Indo-European language.
- atoav 3y ago
  For special terminology an invaluable trick is to search for the wikipedia article in your language and switch the language if possible. Of course this has to be used with caution, but it can help you find the right variant of a word.
- Cicero22 3y ago
  A third dev locale worth considering is one which consists of random emojis. Makes it very easy to find hardcoded strings.
- the_imp 3y ago
  Implementing something like an "id" locale is a great idea. Just don't call it that; it's the locale code for Indonesian. Using a word that's longer than three characters like "identity" will help ensure that it won't conflict with a real locale.
scriptsmith 3y ago
Don't forget Right-To-Left languages, that also affects how UI elements are arranged (position within the page) and rendered (input widgets like sliders get reversed).
- yorwba 3y ago
  I think the currently blessed CSS solution is to only use {inline,block}-{start,end} https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical... in place of {left,right,top,bottom} which then automagically supports even vertical scripts like Traditional Mongolian, but most people probably don't think that far ahead when just starting out.
  - qingcharles 3y ago
    I know Traditional Mongolian comes up regularly in i18n contexts, but I've never taken the time to see if it's something an app should support, based on how actively it is used. It seems like it's too minor, mostly due to the fact that nobody could be bothered to support it in electronic formats. Vertical Japanese is very common in the print magazines I read, and is RTL amongst the rest of the Japanese text which is LTR. I just don't see it much online because of the trouble of setting it. If I ever have too much spare time I must try to support vertical Mongolian in my app.
dheerajvs 3y ago
With formatjs [0], you don't have to split the sentence for interpolation. The same example as in the article can be implemented as: const message = defineMessage({ defaultMessage: 'Learn more about <a>supported images</a>.', description: 'Footer text containing a hyperlink', }) and the anchor element can be interpolated as: formatMessage(message, { a: (chunks: ReactNode) => <a href="#link">{chunks}</a>, }) [0]: https://formatjs.io https://formatjs.io
- Cthulhu_ 3y ago
  My weapon of choice is i18next, which elegantly handles inline markup, even nested translations really well (although this example has less than ideal keys) <Trans i18nKey="userMessagesUnread" count={count}> Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>. </Trans>
  - thanatropism 3y ago
    My biggest issue with i18n is not the grammar. It's the sheer uncanny valley of it. There are translations to "Hello" in Portuguese but I'd cringe at being greeted with them by a webmail client instead of the more formal Good Morning/Afternoon. The formal/informal gradient is very culture-bound and even hard to pin to a scalar space of possibilities. In a work environment people will fluently code-switch too -- say, between ranks or in the middle of a tiresome meeting when everyone takes five minutes to kick back and comment on lighter matters. It's hard to situate a computer in this social context.
draw_down 3y ago
[dead]
dolmen 3y ago
The post is interesting as it exposes the problem statement. Unfortunately, I expected from a Shopify Engineering blog that it would provide solutions to this problem like a JS library for i18n. Disclaimer: As I'm not a frontend developer I'm not familiar with the ecosystem solutions.
- Etheryte 3y ago
  The article shows solutions and they're library agnostic, you can use the approaches shown in pretty much any modern intl library.
Wildgoose 3y ago
Another aspect to be aware of is that English is often much shorter than the equivalent translated text, especially on buttons with text labels. I remember many years ago we used a rough rule of thumb of always doubling the space used for English to ensure there was enough space for the translated text.
- jakub_g 3y ago
  Non-latin fonts also have different glyph widths. For example cyryllic text might be same "length" but glyphs in a system font might be wider hence overall the string needs more space.
- Cthulhu_ 3y ago
  While developing, it's a good practice to have at least "lorem ipsum" or auto translated versions of the phrases in your product, if you're targeting multiple languages. Likewise though, character based languages like Chinese CAN be a lot more compact than English. But counterpoint, those same languages have a different internet culture where they will put more information in headlines. Random website I looked up; https://cn.chinadaily.com.cn/ https://cn.chinadaily.com.cn/ has a small header in a sidebar: 数读中国 | 韧性强活力足信心稳外贸外资稳中提质 But it translates to something that's three times as long in English: Data Reading China | Resilience is strong, vitality is sufficient, confidence is stable, foreign trade and foreign investment are stable and quality is improving Another thing to keep in mind for development: right-to-left languages like Arabic, Hebrew, Persian, Urdu, Kashmiri, Pashto, Uighur, Sorani Kurdish, Punjabi, and Sindhi. I was lucky to be involved in a very international website that also had a Hebrew version, the CSS developers (another luck, we had dedicated CSS developers) even made the site layout right-to-left on RTL languages.
- rickspencer3 3y ago
  Years ago when I worked at Microsoft, they had a "pseudo localization" tool, at least for Visual Studio, that would inject backwards text, longer text, etc... It was gibberish, but it gave QA instant feedback on whether the UI would accommodate the localization process. I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog: https://www.shopify.com/partners/blog/pseudo-localization https://www.shopify.com/partners/blog/pseudo-localization.
JanSt 3y ago
Is there some kind of Auto-i18n where the function sends a request to a server if there is no localization available? The server could in turn request a translation from a service and add it to the localization files
- gorbypark 3y ago
  This does exist, there are a few translation-as-a-service companies that offer more or less what you want. It's not exactly as you are describing, but I have a pipeline setup for an app I built that will extract and machine translate strings at build time. It would be pretty trivial to just do the extraction part and send off the files to whatever endpoint you want (being a human or a machine translating in the end), if you wanted to "roll your own".
- majido 3y ago
  I believe the library mentioned in the article (i18next) provides the necessary hooks to do this. See ‘saveMissing’ option [1]. Though you need a backend to save this and manage translations. The maintainer of that library, locize, business model is to provide such a service. [1] https://www.i18next.com/how-to/extracting-translations https://www.i18next.com/how-to/extracting-translations
  - gorbypark 3y ago
    There’s a really nice babel plugin as well that can do the extraction.
AndrewOMartin 3y ago
It's best practice to shorten "Internationalization (i18n)" to "I25)"
lucideer 3y ago
This is a good article, though as someone who prefers references/tables to prose for technical topics, the real find for me was the link out to the Unicode CLDR project (which sadly contains a LOT of broken links right now due to a data migration effort but I'll bookmark it & hopefully it'll be navigable in future). As someone with a Polish partner, who also fluently speaks my own weird minority local language (Irish), I'm more than well aware of pluralisation pitfalls; Irish may have one of the most complex rulesets, so much so that I'm almost certain it isn't represented in CDLR (possibly can't be). But I see the plural pitfall brought up in so many of these guide - I've always been curious about other unexpected/unintuitive pitfalls across languages out there. Would love if there was a simple reference of the most interesting (starting with plurals I guess).
- yorwba 3y ago
  The CLDR plural rules for Irish are here https://www.unicode.org/cldr/charts/42/supplemental/language_plural_rules.html#ga https://www.unicode.org/cldr/charts/42/supplemental/language... Not quite as complex as the ones for Breton https://www.unicode.org/cldr/charts/42/supplemental/language_plural_rules.html#br https://www.unicode.org/cldr/charts/42/supplemental/language... but of course they might be wrong.
  - lucideer 3y ago
    Both of these only cover case changes for the object being counted: cases are pretty common across non-English languages so this is simple enough on its own. The main difference I see in Breton is the rules for 1-9 follow through for double-digits n1-n9 - I would've suspected this to be true for Irish but I just speak it, don't study it, so confidence in my grammatical knowledge is low. Irish definitely doesn't have the exceptions for 71-79 & 91-99; this smells like French influence. The main thing missing from both of these though is modifications to the actual words for numerals: they kind of get away with it by sticking to digits, but I'm not sure if that's always the case in the translated output of i18n libraries referencing this. If they're ever outputting words in place of numerical digits then these are both very incomplete. Irish then also has an entirely different way of counting persons which isn't included.
bitigchi 3y ago
Also, number and percent formats are important too. I've seen many 'professional' websites/software, that uses only a standart 100.0% format, where the decimal and the percent are not localised.
ChrisMarshallNY 3y ago
I've found that I need to support localization from the very start. I never display a quoted string. I always use Apple's tokenization (or create my own, if doing server code). Apple has terrific support for localization, which puts the onus on us, to honor it. I have some basic extensions that I use to support localization in my coding[0-2], but there's also just stuff I need to keep in mind, all the time. There has been discussion of how to deal with things like word order in different languages. For example, in Germanic languages, the modifier usually precedes the subject, while in Romance languages, it tends to be the opposite. Thankfully, Apple supports the "$" format for sprintf strings[3], so we can do stuff like this: import Foundation let localizationAssets = [ (format: "The %1$@ %2$@", modifier: "white", subject: "horse"), (format: "Le %2$@ %1$@", modifier: "blanc", subject: "cheval") ] func localizedHorse(_ inLocalization: Int) -> String { String( format: localizationAssets[inLocalization].format, localizationAssets[inLocalization].modifier, localizationAssets[inLocalization].subject ) } // English (Prints "The white horse") print(localizedHorse(0)) // French (Prints "Le cheval blanc") print(localizedHorse(1)) [0] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Toolbox/blob/master/Sources/RVS_Generic_Swift_Toolbox/RVS_Generic_Swift_Toolbox_Extensions/RVS_Foundation_Extensions.swift#L184 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool... [1] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Toolbox/blob/master/Sources/RVS_Generic_Swift_Toolbox/RVS_Generic_Swift_Toolbox_Extensions/RVS_Foundation_Extensions.swift#L192 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool... [2] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Toolbox/blob/master/Sources/RVS_Generic_Swift_Toolbox/RVS_Generic_Swift_Toolbox_Extensions/RVS_Foundation_Extensions.swift#L200 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool... [3] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html#//apple_ref/doc/uid/TP40004265-SW2 https://developer.apple.com/library/archive/documentation/Co...
- trinix912 3y ago
  The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in its entirety. Avoid interpolating nouns, adjectives, verbs etc. as much as possible.
Kiala 3y ago
> The order of the words is hardcoded, with “added” preceding the date. This would be incorrect in many languages, from Dutch (“1 januari toegevoegd”) This is simply not true. Since English and Dutch are both Germanic languages they largely work the same way. Saying "Toegevoegd: 1 januari" would be just fine. By using "1 januari toevoegd" you're syntactically changing the sentence.
- irishsultan 3y ago
  1 januari toegevoegd sounds like you're adding the date. If you're going to write it as a sentence it ought to have something like "Op 1 januari", and in that case it actually doesn't matter whether you put the toegevoegd before or after "op 1 januari". But I agree, nothing wrong with "Toegevoegd: 1 januari".
jakub_g 3y ago
Good article. Knowing some Slavic, Latin or Asian language helps immensely when dealing with i18n. I wrote an article on a similar subject (with some additional technical details about Android and iOS) a few years ago, with a few similar conclusions: https://jakub.gieryluk.net/blog/reusing-software-translations-ios-android-web/ https://jakub.gieryluk.net/blog/reusing-software-translation...
sergioisidoro 3y ago
It's frustrating that the post does not provide any solution for some of the problems like declinations and gender. I internationalised a couple of applications, and it's incredible how i18n frameworks are still so limited in linguistic aspects that are so important for so many languages. Finnish, for example works with a ton of suffixes, and you end up having to rewrite the copy (to non natural structures) to fit interpolation and declinations. Portuguese genders almost every subject in a phrase construction. The web is killing (or creating artificial versions) of many languages because the lack of tooling...
- Cthulhu_ 3y ago
  i18next has that covered, as well as all the other issues mentioned: https://www.i18next.com/translation-function/context https://www.i18next.com/translation-function/context (note that I don't fully understand gendered languages, the above may or may not be applicable)
- imran-iq 3y ago
  Good news is folks are working on better tooling, for example fluent[0] by mozilla. The bad news though is adoption. --- 0: https://projectfluent.org/ https://projectfluent.org/
  - troad 3y ago
    Fluent is terrible. I excitedly implemented it in my most recent app, and immediately ran into so many issues. 1) It can transclude variables in translation strings, but these variables cannot themselves be localised. This makes Fluent completely useless for constructions like “Your knight has killed a dragon with a crossbow” in any language with case or gender, unless you pre-translate every possible combination in advance. Which is absurd - the possible combinations almost immediately grow astronomical. 2) The parser is extremely sensitive, and it produces errors which are terse and difficult to debug. Something as basic as a localisation key appearing twice throws an unrecoverable exception. 3) The input files mandate a weird arrangement of new lines for even the simplest branching (e.g. 1 -> cat, 2+ -> cats), which makes them become incredibly difficult to follow. I quickly lost track of my own reference English file - good luck giving them to translator to figure out for any languages with greater grammatical complexity. 4) The documentation is too Spartan to know what happens in edge cases. The word “Fluent” does not restrict language-related web searches in any useful way. I worked around issue 1 with some ugly nested localisation hacks, but I plan to rip Fluent out before release. It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.
lakomen 3y ago
I name them by component.context.phrase There's https://cldr.unicode.org/index . In Angular I liked Transloco [0] very much. For Vue I use vue-i18n, I don't think there's any alternative. For Go I like go-i18n [1] when doing SSR Go. For Svelte.. not sure if there's a best package. [0] https://github.com/ngneat/transloco [1] https://github.com/nicksnyder/go-i18n
needle0 3y ago
Not covered here: fonts and glyph appearances, which will nearly always end up displaying wrong in certain Asian languages -- https://heistak.github.io/your-code-displays-japanese-wrong/ https://heistak.github.io/your-code-displays-japanese-wrong/
- qingcharles 3y ago
  Thank you for this. I tested it immediately on my site. Now, during testing I looked at the debug output before I browsed to a page, and the debug output was displaying the wrong characters, hanzi instead of kanji. But, when I browsed to the actual page, the characters were right, presumably because I'm setting the lang attribute in the HTML tag. Thank god I did that. Still, testing this uncovered a bug in my Traditional Chinese code, so there's that to fix now :)
dale_glass 3y ago
A particularly tricky case of this is with usernames and user defined content. Eg, a notification like "Alice is online" in some languages requires knowing Alice's gender. Which may be something that's not even stored anywhere in the system. There's probably some language out there that requires some other piece of personal info for a correct translation. To make things tricky, try having a multitude of items that you refer to: "You're holding a dagger". Now you need to have a serious discussion with your translators, because this is going to get all kinds of tricky, as the maker of Obra Dinn discovered: https://www.youtube.com/watch?v=OMi6xgdSbMA https://www.youtube.com/watch?v=OMi6xgdSbMA And to make things extra-tricky, allow users to create content. "Alice gave you a banana", where "banana" is a custom object Alice made herself. Most translation efforts seem to give up at this point and resort to something stilted like "Alice: online"
- deleted 3y ago
  [deleted]
- jimmywetnips 3y ago
  I think most common languages you can either choose between a combo adjective like Alice es activo(a) Or alice es activ@ But honestly as engineers, we should follow the advice of making the stilted constructions. We're already trained as users to expect that anyways from all the other apps. If it's just a monolingual app. Sure go nuts, make it read super fluidly. If you have to localize, just do it the tried and true way
  - dejj 3y ago
    @ as a superposition of “a” and “o”; very nice. If gender is how we sneak conditional expressions and nondet Prolog predicates into natural languages, then I’m in.
  - ggrrhh_ta 3y ago
    In this particular case, only "está" (instead of "es") is correct. Otherwise it means that the person is an active person, instead of meaning that at the present period of time, the person can be found active/online.
h1fra 3y ago
Translation/Internationalisation is one of the hardest problem that is not going to be solved by technology only. RTL, plural depending on the number, non-latin char behavior, font issues, UI broken by longer translation, context dependent translation, etc. Every time I start a project or think about it I'm sweating.
- draw_down 3y ago
  I don’t see any real way to deal with it except overstaffing (not gonna happen), designing everything into discrete horizontal lines, or simply coming to terms with the idea that some locales will break more than others, depending on who you are and who your customer base is. And deciding what you’re gonna do about that when it arises. Buttons are gonna look jacked up in German because all their words are 45 letters long. RTL plays havoc with the layout. Referring to Taiwan the wrong way is a Defcon 2 political crisis. And on and on and on, it never fucking ends.
- samuelstros 3y ago
  well, at least we are trying to solve i18n with tech https://github.com/inlang/inlang https://github.com/inlang/inlang :D
samuelstros 3y ago
i am on a 2 year long rabbit hole to solve many i18n problems that devs face https://github.com/inlang/inlang https://github.com/inlang/inlang we are in our third (major) refactor because the problem is so complex and new requirements emerge regularly :/
barbariangrunge 3y ago
I’m highly procedural game dev lots of text has unpredictable text inserted within it. Eg, a notification for how “(person 1) has left (room1) to perform (action) in (room2) with (item1)” So your “never do interpolation” trick is a bit of an over-simplification already. Not to mention all the ways to modify a verb or noun with surrounding words, Eg, preceding it with the. I walked to Larry vs I walked to the couch Our languages systems for our game got pretty complex, pretty fast, and I find these simplified hand wavy articles pretty frustrating tbh
higgins 3y ago
tangent: did you know that "institutionalization" also resolves to the English numerical contraction: "i18n"? here's a tool to test for conflicts in other words (a11y, k8s, ets): https://encapsulate.me/writing/e25n.html https://encapsulate.me/writing/e25n.html
- mtlmtlmtlmtl 3y ago
  I hate these numerical contractions. I have no intuitive knowledge of how many characters words have even if I'm seeing them spelled out, let alone trying to do it in reverse.
  - higgins 3y ago
    l1l
MilStdJunkie 3y ago
I would give my little toe to see what this person's opinion is on CCS/CCMS (Component Content Systems) https://en.wikipedia.org/wiki/Component_content_management_system https://en.wikipedia.org/wiki/Component_content_management_s... There's quite a bit more to be written here about natural language, formal language, and how constituents of each class interact with each other. Stuff that the initial architects of "component content" were not necessarily thinking about, because they were coming at the problem from an extremely limited corpus.
yafbum 3y ago
Smells: * If you're concatenating sentence bits, you're doing it wrong * If you're formatting numbers, dates, times, or durations by hand, you're doing it wrong * If you're formatting strings with placeholders and you don't know the gender and number of your placeholders, your translators are going to have a bad time There are two more important rules that this article doesn't mention * Write long descriptions of what the thing is that you're asking someone to translate (button label, menu item, dialog header...), and include a screenshot. Translating very short strings without context is very difficult. * Ask your translators to do a global once-over QA pass once in a while to detect inconsistencies and weirdness. Once I dealt with a product that had three tabs, and two of the tabs were translated identically. Each tab header translation made sense on its own, but as distinct tab headers side by side, it made no sense to use the same word.
- troad 3y ago
  > If you're concatenating sentence bits, you're doing it wrong. This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game. E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].” Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy nouns. This is one announcement type out of hundreds in your game (Your green dragon was spotted by an enemy Lizardman! Your attack dirigible is running low on hydrogen!) You’re going to - what - precompose all of this? And pay to have your trillions of lines translated into a dozen languages? At that point it would seem more cost effective to use your i18n budget to finance some kind of monolingual colony on Mars, and just sell your product there. Yes, this is going to be hard to concat programmatically, and yes, you’ll likely make some mistakes and might need to rethink some phrasing. One language’s ‘blue’ is another language’s ‘wine dark’. One language’s adjective (he is tall) is another language’s verb (he towers). But “don’t concatenate” is simply not useful advice, because it is not actually actionable for most projects. People act like i18n is some great moral-ethical challenge, and if you fail, you will mortally offend millions. You won’t. You might sound silly, but people are patient, and you’ll recover. No matter how hard you try and plan, you will, at some point, get localisation wrong. Oh, you’ve thought of gender? That’s great! What about case? Ok, but that only works for languages with nominative-accusative alignment. What about languages with ergative-absolutive alignment? Or a tripartite system? And this is just nouns - wait until we get to verbs!
Tainnor 3y ago
I think the Polish example is even a bit more complex than that: it's not really that Polish has a separate form for "a few". That's the regular plural form. It's that Polish uses the genitive plural with certain numerals, instead of the nominative. That is, instead of saying "5 dogs" you say "5 of dogs". This doesn't, to my knowledge, apply if there is no numeral provided, even if we're talking about 1000 dogs, so it wouldn't be right to call it a plural. Of course, the point of the article still stands. Disclaimer: I don't speak Polish. I did learn some Czech though at some point (most of which I've forgotten).
FlorianZysset 3y ago
Unrelated but I had a weird experience navigating to this article on my IPhone: the music in my headset switched to call mode. I can reproduce that about 50% of the time. Is there something using the microphone somewhere? Feels really weird… 14 Pro Max with latest beta software
zengid 3y ago
Can I just rant for a second about how much I hate the whole `<starting-letter-of-a-word-><count-of-inner-letters><ending-letter-of-a-word>` trend that folks seem to love? This intentional sort of obfuscation makes it hard for juniors or students (the exact people who would be interested in an article like this), to engage in the material. The most egregious example is doing it for the word 'accessibility'!
- Mordisquitos 3y ago
  > <starting-letter-of-a-word-><count-of-inner-letters><ending-letter-of-a-word> Also known as <s73d> for short.

In general a good short rule of thumb is to always always _always_ write out the full sentence you want to translate and use the tooling to interpolate everything you want to put in it. That way the translator always sees the full context and you make it harder (although not impossible) for yourself to shoot yourself in the foot. Another recommendation I would add is to use two meta locales in development in addition to whatever you need to support otherwise: id and pseudo. The id locale should be an identity function so you (and the translator and everyone else) can open up a page and see what keys are used on that page. The pseudo locale should be either random or pseudorandom text and is good for both ensuring you haven't accidentally left something hardcoded as well as checking how your layout plays with different length strings. These ideas alone will get you most of the way most of the time, and they have the added benefit that they're straightforward to teach to juniors.

worklaptopacct 3y ago
Common translation tools would benefit from the ability to input some domain information. Typing in an entire sentence is a sensible start, but oftentimes a lone sentence does not carry enough context. Example: in my language, the term "fresh water" translates to "fresh water" or "sweet water". "Sweet water" is the opposite of saltwater, while "fresh water" would only be used in a context like "water in a tank has been replaced". The translations in Cities: Skylines use the literal translation and this has always irked me; if the translator accepted "plumbing" as a context, it would have produced a correct translation.
- Etheryte 3y ago
  Most common translation tools already support this. From GNU gettext where it's called context [0], to FormatJS where it's called a description [1], all translation tools worth their salt support providing additional information about the usage. The problem is generally not on the tooling side but on the awareness side, if the person implementing the feature only speaks one language it's easy to overlook issues that wouldn't occur in their native language. [0] https://www.gnu.org/software/gettext/manual/gettext.html#Contexts https://www.gnu.org/software/gettext/manual/gettext.html#Con... [1] https://formatjs.io/docs/intl/#message-descriptor https://formatjs.io/docs/intl/#message-descriptor
  - holoduke 3y ago
    If you can tell me how to provide context in the google translation api i would be very happy. Dont think it exists. Only in the web version.
- Kerrick 3y ago
  For what it's worth, the term "fresh water" has each of those separate connotations in American English too, and it can be just as context-dependent. Both "These fish belong in fresh water, not salt water" and "I put fresh water in the ice trays because the old stuff was stale" are valid contextually and linguistically.
  - fjkdlsjflkds 3y ago
    Yes, but it does not necessarily have those two connotations in other languages (which is the issue here). In Portuguese, if you want to say "fresh water" (as in, "low-salinity water"), you use the term "sweet water", rather than "fresh water" ("fresh water" can only be interpreted either as "cold water" or "non-stale water", but never as "low-salinity water").
- p3rls 3y ago
  In English we have the term potable to designate drinkable water, which comes from an old PIEish verb meaning to drink that no one uses anymore and so it's often confused with "pottable" i.e., to be put into a pot, as in a game of pool (a non-aquatic table sport fyi)
  - dejj 3y ago
    What does PIEish mean?
    - mablopoule 3y ago
      Not op, but I think it stands for Proto-Indo-European language.
atoav 3y ago
For special terminology an invaluable trick is to search for the wikipedia article in your language and switch the language if possible. Of course this has to be used with caution, but it can help you find the right variant of a word.
Cicero22 3y ago
A third dev locale worth considering is one which consists of random emojis. Makes it very easy to find hardcoded strings.
the_imp 3y ago
Implementing something like an "id" locale is a great idea. Just don't call it that; it's the locale code for Indonesian. Using a word that's longer than three characters like "identity" will help ensure that it won't conflict with a real locale.

scriptsmith 3y ago

Don't forget Right-To-Left languages, that also affects how UI elements are arranged (position within the page) and rendered (input widgets like sliders get reversed).

yorwba 3y ago
I think the currently blessed CSS solution is to only use {inline,block}-{start,end} https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical... in place of {left,right,top,bottom} which then automagically supports even vertical scripts like Traditional Mongolian, but most people probably don't think that far ahead when just starting out.
- qingcharles 3y ago
  I know Traditional Mongolian comes up regularly in i18n contexts, but I've never taken the time to see if it's something an app should support, based on how actively it is used. It seems like it's too minor, mostly due to the fact that nobody could be bothered to support it in electronic formats. Vertical Japanese is very common in the print magazines I read, and is RTL amongst the rest of the Japanese text which is LTR. I just don't see it much online because of the trouble of setting it. If I ever have too much spare time I must try to support vertical Mongolian in my app.

dheerajvs 3y ago

With formatjs [0], you don't have to split the sentence for interpolation. The same example as in the article can be implemented as: const message = defineMessage({ defaultMessage: 'Learn more about <a>supported images</a>.', description: 'Footer text containing a hyperlink', }) and the anchor element can be interpolated as: formatMessage(message, { a: (chunks: ReactNode) => <a href="#link">{chunks}</a>, }) [0]: https://formatjs.io https://formatjs.io

Cthulhu_ 3y ago
My weapon of choice is i18next, which elegantly handles inline markup, even nested translations really well (although this example has less than ideal keys) <Trans i18nKey="userMessagesUnread" count={count}> Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>. </Trans>
- thanatropism 3y ago
  My biggest issue with i18n is not the grammar. It's the sheer uncanny valley of it. There are translations to "Hello" in Portuguese but I'd cringe at being greeted with them by a webmail client instead of the more formal Good Morning/Afternoon. The formal/informal gradient is very culture-bound and even hard to pin to a scalar space of possibilities. In a work environment people will fluently code-switch too -- say, between ranks or in the middle of a tiresome meeting when everyone takes five minutes to kick back and comment on lighter matters. It's hard to situate a computer in this social context.

draw_down 3y ago

[dead]

dolmen 3y ago

The post is interesting as it exposes the problem statement. Unfortunately, I expected from a Shopify Engineering blog that it would provide solutions to this problem like a JS library for i18n. Disclaimer: As I'm not a frontend developer I'm not familiar with the ecosystem solutions.

Etheryte 3y ago
The article shows solutions and they're library agnostic, you can use the approaches shown in pretty much any modern intl library.

Wildgoose 3y ago

Another aspect to be aware of is that English is often much shorter than the equivalent translated text, especially on buttons with text labels. I remember many years ago we used a rough rule of thumb of always doubling the space used for English to ensure there was enough space for the translated text.

jakub_g 3y ago
Non-latin fonts also have different glyph widths. For example cyryllic text might be same "length" but glyphs in a system font might be wider hence overall the string needs more space.
Cthulhu_ 3y ago
While developing, it's a good practice to have at least "lorem ipsum" or auto translated versions of the phrases in your product, if you're targeting multiple languages. Likewise though, character based languages like Chinese CAN be a lot more compact than English. But counterpoint, those same languages have a different internet culture where they will put more information in headlines. Random website I looked up; https://cn.chinadaily.com.cn/ https://cn.chinadaily.com.cn/ has a small header in a sidebar: 数读中国 | 韧性强活力足信心稳外贸外资稳中提质 But it translates to something that's three times as long in English: Data Reading China | Resilience is strong, vitality is sufficient, confidence is stable, foreign trade and foreign investment are stable and quality is improving Another thing to keep in mind for development: right-to-left languages like Arabic, Hebrew, Persian, Urdu, Kashmiri, Pashto, Uighur, Sorani Kurdish, Punjabi, and Sindhi. I was lucky to be involved in a very international website that also had a Hebrew version, the CSS developers (another luck, we had dedicated CSS developers) even made the site layout right-to-left on RTL languages.
rickspencer3 3y ago
Years ago when I worked at Microsoft, they had a "pseudo localization" tool, at least for Visual Studio, that would inject backwards text, longer text, etc... It was gibberish, but it gave QA instant feedback on whether the UI would accommodate the localization process. I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog: https://www.shopify.com/partners/blog/pseudo-localization https://www.shopify.com/partners/blog/pseudo-localization.

JanSt 3y ago

Is there some kind of Auto-i18n where the function sends a request to a server if there is no localization available? The server could in turn request a translation from a service and add it to the localization files

gorbypark 3y ago
This does exist, there are a few translation-as-a-service companies that offer more or less what you want. It's not exactly as you are describing, but I have a pipeline setup for an app I built that will extract and machine translate strings at build time. It would be pretty trivial to just do the extraction part and send off the files to whatever endpoint you want (being a human or a machine translating in the end), if you wanted to "roll your own".
majido 3y ago
I believe the library mentioned in the article (i18next) provides the necessary hooks to do this. See ‘saveMissing’ option [1]. Though you need a backend to save this and manage translations. The maintainer of that library, locize, business model is to provide such a service. [1] https://www.i18next.com/how-to/extracting-translations https://www.i18next.com/how-to/extracting-translations
- gorbypark 3y ago
  There’s a really nice babel plugin as well that can do the extraction.

AndrewOMartin 3y ago

It's best practice to shorten "Internationalization (i18n)" to "I25)"

lucideer 3y ago

This is a good article, though as someone who prefers references/tables to prose for technical topics, the real find for me was the link out to the Unicode CLDR project (which sadly contains a LOT of broken links right now due to a data migration effort but I'll bookmark it & hopefully it'll be navigable in future). As someone with a Polish partner, who also fluently speaks my own weird minority local language (Irish), I'm more than well aware of pluralisation pitfalls; Irish may have one of the most complex rulesets, so much so that I'm almost certain it isn't represented in CDLR (possibly can't be). But I see the plural pitfall brought up in so many of these guide - I've always been curious about other unexpected/unintuitive pitfalls across languages out there. Would love if there was a simple reference of the most interesting (starting with plurals I guess).

yorwba 3y ago
The CLDR plural rules for Irish are here https://www.unicode.org/cldr/charts/42/supplemental/language_plural_rules.html#ga https://www.unicode.org/cldr/charts/42/supplemental/language... Not quite as complex as the ones for Breton https://www.unicode.org/cldr/charts/42/supplemental/language_plural_rules.html#br https://www.unicode.org/cldr/charts/42/supplemental/language... but of course they might be wrong.
- lucideer 3y ago
  Both of these only cover case changes for the object being counted: cases are pretty common across non-English languages so this is simple enough on its own. The main difference I see in Breton is the rules for 1-9 follow through for double-digits n1-n9 - I would've suspected this to be true for Irish but I just speak it, don't study it, so confidence in my grammatical knowledge is low. Irish definitely doesn't have the exceptions for 71-79 & 91-99; this smells like French influence. The main thing missing from both of these though is modifications to the actual words for numerals: they kind of get away with it by sticking to digits, but I'm not sure if that's always the case in the translated output of i18n libraries referencing this. If they're ever outputting words in place of numerical digits then these are both very incomplete. Irish then also has an entirely different way of counting persons which isn't included.

bitigchi 3y ago

Also, number and percent formats are important too. I've seen many 'professional' websites/software, that uses only a standart 100.0% format, where the decimal and the percent are not localised.

ChrisMarshallNY 3y ago

I've found that I need to support localization from the very start. I never display a quoted string. I always use Apple's tokenization (or create my own, if doing server code). Apple has terrific support for localization, which puts the onus on us, to honor it. I have some basic extensions that I use to support localization in my coding[0-2], but there's also just stuff I need to keep in mind, all the time. There has been discussion of how to deal with things like word order in different languages. For example, in Germanic languages, the modifier usually precedes the subject, while in Romance languages, it tends to be the opposite. Thankfully, Apple supports the "$" format for sprintf strings[3], so we can do stuff like this: import Foundation let localizationAssets = [ (format: "The %1$@ %2$@", modifier: "white", subject: "horse"), (format: "Le %2$@ %1$@", modifier: "blanc", subject: "cheval") ] func localizedHorse(_ inLocalization: Int) -> String { String( format: localizationAssets[inLocalization].format, localizationAssets[inLocalization].modifier, localizationAssets[inLocalization].subject ) } // English (Prints "The white horse") print(localizedHorse(0)) // French (Prints "Le cheval blanc") print(localizedHorse(1)) [0] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Toolbox/blob/master/Sources/RVS_Generic_Swift_Toolbox/RVS_Generic_Swift_Toolbox_Extensions/RVS_Foundation_Extensions.swift#L184 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool... [1] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Toolbox/blob/master/Sources/RVS_Generic_Swift_Toolbox/RVS_Generic_Swift_Toolbox_Extensions/RVS_Foundation_Extensions.swift#L192 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool... [2] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Toolbox/blob/master/Sources/RVS_Generic_Swift_Toolbox/RVS_Generic_Swift_Toolbox_Extensions/RVS_Foundation_Extensions.swift#L200 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool... [3] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html#//apple_ref/doc/uid/TP40004265-SW2 https://developer.apple.com/library/archive/documentation/Co...

trinix912 3y ago
The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in its entirety. Avoid interpolating nouns, adjectives, verbs etc. as much as possible.

Kiala 3y ago

> The order of the words is hardcoded, with “added” preceding the date. This would be incorrect in many languages, from Dutch (“1 januari toegevoegd”) This is simply not true. Since English and Dutch are both Germanic languages they largely work the same way. Saying "Toegevoegd: 1 januari" would be just fine. By using "1 januari toevoegd" you're syntactically changing the sentence.

irishsultan 3y ago
1 januari toegevoegd sounds like you're adding the date. If you're going to write it as a sentence it ought to have something like "Op 1 januari", and in that case it actually doesn't matter whether you put the toegevoegd before or after "op 1 januari". But I agree, nothing wrong with "Toegevoegd: 1 januari".

jakub_g 3y ago

Good article. Knowing some Slavic, Latin or Asian language helps immensely when dealing with i18n. I wrote an article on a similar subject (with some additional technical details about Android and iOS) a few years ago, with a few similar conclusions: https://jakub.gieryluk.net/blog/reusing-software-translations-ios-android-web/ https://jakub.gieryluk.net/blog/reusing-software-translation...

sergioisidoro 3y ago

It's frustrating that the post does not provide any solution for some of the problems like declinations and gender. I internationalised a couple of applications, and it's incredible how i18n frameworks are still so limited in linguistic aspects that are so important for so many languages. Finnish, for example works with a ton of suffixes, and you end up having to rewrite the copy (to non natural structures) to fit interpolation and declinations. Portuguese genders almost every subject in a phrase construction. The web is killing (or creating artificial versions) of many languages because the lack of tooling...

Cthulhu_ 3y ago
i18next has that covered, as well as all the other issues mentioned: https://www.i18next.com/translation-function/context https://www.i18next.com/translation-function/context (note that I don't fully understand gendered languages, the above may or may not be applicable)
imran-iq 3y ago
Good news is folks are working on better tooling, for example fluent[0] by mozilla. The bad news though is adoption. --- 0: https://projectfluent.org/ https://projectfluent.org/
- troad 3y ago
  Fluent is terrible. I excitedly implemented it in my most recent app, and immediately ran into so many issues. 1) It can transclude variables in translation strings, but these variables cannot themselves be localised. This makes Fluent completely useless for constructions like “Your knight has killed a dragon with a crossbow” in any language with case or gender, unless you pre-translate every possible combination in advance. Which is absurd - the possible combinations almost immediately grow astronomical. 2) The parser is extremely sensitive, and it produces errors which are terse and difficult to debug. Something as basic as a localisation key appearing twice throws an unrecoverable exception. 3) The input files mandate a weird arrangement of new lines for even the simplest branching (e.g. 1 -> cat, 2+ -> cats), which makes them become incredibly difficult to follow. I quickly lost track of my own reference English file - good luck giving them to translator to figure out for any languages with greater grammatical complexity. 4) The documentation is too Spartan to know what happens in edge cases. The word “Fluent” does not restrict language-related web searches in any useful way. I worked around issue 1 with some ugly nested localisation hacks, but I plan to rip Fluent out before release. It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.

lakomen 3y ago

I name them by component.context.phrase There's https://cldr.unicode.org/index . In Angular I liked Transloco [0] very much. For Vue I use vue-i18n, I don't think there's any alternative. For Go I like go-i18n [1] when doing SSR Go. For Svelte.. not sure if there's a best package. [0] https://github.com/ngneat/transloco [1] https://github.com/nicksnyder/go-i18n

needle0 3y ago

Not covered here: fonts and glyph appearances, which will nearly always end up displaying wrong in certain Asian languages -- https://heistak.github.io/your-code-displays-japanese-wrong/ https://heistak.github.io/your-code-displays-japanese-wrong/

qingcharles 3y ago
Thank you for this. I tested it immediately on my site. Now, during testing I looked at the debug output before I browsed to a page, and the debug output was displaying the wrong characters, hanzi instead of kanji. But, when I browsed to the actual page, the characters were right, presumably because I'm setting the lang attribute in the HTML tag. Thank god I did that. Still, testing this uncovered a bug in my Traditional Chinese code, so there's that to fix now :)

dale_glass 3y ago

A particularly tricky case of this is with usernames and user defined content. Eg, a notification like "Alice is online" in some languages requires knowing Alice's gender. Which may be something that's not even stored anywhere in the system. There's probably some language out there that requires some other piece of personal info for a correct translation. To make things tricky, try having a multitude of items that you refer to: "You're holding a dagger". Now you need to have a serious discussion with your translators, because this is going to get all kinds of tricky, as the maker of Obra Dinn discovered: https://www.youtube.com/watch?v=OMi6xgdSbMA https://www.youtube.com/watch?v=OMi6xgdSbMA And to make things extra-tricky, allow users to create content. "Alice gave you a banana", where "banana" is a custom object Alice made herself. Most translation efforts seem to give up at this point and resort to something stilted like "Alice: online"

deleted 3y ago
[deleted]
jimmywetnips 3y ago
I think most common languages you can either choose between a combo adjective like Alice es activo(a) Or alice es activ@ But honestly as engineers, we should follow the advice of making the stilted constructions. We're already trained as users to expect that anyways from all the other apps. If it's just a monolingual app. Sure go nuts, make it read super fluidly. If you have to localize, just do it the tried and true way
- dejj 3y ago
  @ as a superposition of “a” and “o”; very nice. If gender is how we sneak conditional expressions and nondet Prolog predicates into natural languages, then I’m in.
- ggrrhh_ta 3y ago
  In this particular case, only "está" (instead of "es") is correct. Otherwise it means that the person is an active person, instead of meaning that at the present period of time, the person can be found active/online.

h1fra 3y ago

Translation/Internationalisation is one of the hardest problem that is not going to be solved by technology only. RTL, plural depending on the number, non-latin char behavior, font issues, UI broken by longer translation, context dependent translation, etc. Every time I start a project or think about it I'm sweating.

draw_down 3y ago
I don’t see any real way to deal with it except overstaffing (not gonna happen), designing everything into discrete horizontal lines, or simply coming to terms with the idea that some locales will break more than others, depending on who you are and who your customer base is. And deciding what you’re gonna do about that when it arises. Buttons are gonna look jacked up in German because all their words are 45 letters long. RTL plays havoc with the layout. Referring to Taiwan the wrong way is a Defcon 2 political crisis. And on and on and on, it never fucking ends.
samuelstros 3y ago
well, at least we are trying to solve i18n with tech https://github.com/inlang/inlang https://github.com/inlang/inlang :D

samuelstros 3y ago

i am on a 2 year long rabbit hole to solve many i18n problems that devs face https://github.com/inlang/inlang https://github.com/inlang/inlang we are in our third (major) refactor because the problem is so complex and new requirements emerge regularly :/

barbariangrunge 3y ago

I’m highly procedural game dev lots of text has unpredictable text inserted within it. Eg, a notification for how “(person 1) has left (room1) to perform (action) in (room2) with (item1)” So your “never do interpolation” trick is a bit of an over-simplification already. Not to mention all the ways to modify a verb or noun with surrounding words, Eg, preceding it with the. I walked to Larry vs I walked to the couch Our languages systems for our game got pretty complex, pretty fast, and I find these simplified hand wavy articles pretty frustrating tbh

higgins 3y ago

tangent: did you know that "institutionalization" also resolves to the English numerical contraction: "i18n"? here's a tool to test for conflicts in other words (a11y, k8s, ets): https://encapsulate.me/writing/e25n.html https://encapsulate.me/writing/e25n.html

mtlmtlmtlmtl 3y ago
I hate these numerical contractions. I have no intuitive knowledge of how many characters words have even if I'm seeing them spelled out, let alone trying to do it in reverse.
- higgins 3y ago
  l1l

MilStdJunkie 3y ago

I would give my little toe to see what this person's opinion is on CCS/CCMS (Component Content Systems) https://en.wikipedia.org/wiki/Component_content_management_system https://en.wikipedia.org/wiki/Component_content_management_s... There's quite a bit more to be written here about natural language, formal language, and how constituents of each class interact with each other. Stuff that the initial architects of "component content" were not necessarily thinking about, because they were coming at the problem from an extremely limited corpus.

yafbum 3y ago

Smells: * If you're concatenating sentence bits, you're doing it wrong * If you're formatting numbers, dates, times, or durations by hand, you're doing it wrong * If you're formatting strings with placeholders and you don't know the gender and number of your placeholders, your translators are going to have a bad time There are two more important rules that this article doesn't mention * Write long descriptions of what the thing is that you're asking someone to translate (button label, menu item, dialog header...), and include a screenshot. Translating very short strings without context is very difficult. * Ask your translators to do a global once-over QA pass once in a while to detect inconsistencies and weirdness. Once I dealt with a product that had three tabs, and two of the tabs were translated identically. Each tab header translation made sense on its own, but as distinct tab headers side by side, it made no sense to use the same word.

troad 3y ago
> If you're concatenating sentence bits, you're doing it wrong. This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game. E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].” Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy nouns. This is one announcement type out of hundreds in your game (Your green dragon was spotted by an enemy Lizardman! Your attack dirigible is running low on hydrogen!) You’re going to - what - precompose all of this? And pay to have your trillions of lines translated into a dozen languages? At that point it would seem more cost effective to use your i18n budget to finance some kind of monolingual colony on Mars, and just sell your product there. Yes, this is going to be hard to concat programmatically, and yes, you’ll likely make some mistakes and might need to rethink some phrasing. One language’s ‘blue’ is another language’s ‘wine dark’. One language’s adjective (he is tall) is another language’s verb (he towers). But “don’t concatenate” is simply not useful advice, because it is not actually actionable for most projects. People act like i18n is some great moral-ethical challenge, and if you fail, you will mortally offend millions. You won’t. You might sound silly, but people are patient, and you’ll recover. No matter how hard you try and plan, you will, at some point, get localisation wrong. Oh, you’ve thought of gender? That’s great! What about case? Ok, but that only works for languages with nominative-accusative alignment. What about languages with ergative-absolutive alignment? Or a tripartite system? And this is just nouns - wait until we get to verbs!

Tainnor 3y ago

I think the Polish example is even a bit more complex than that: it's not really that Polish has a separate form for "a few". That's the regular plural form. It's that Polish uses the genitive plural with certain numerals, instead of the nominative. That is, instead of saying "5 dogs" you say "5 of dogs". This doesn't, to my knowledge, apply if there is no numeral provided, even if we're talking about 1000 dogs, so it wouldn't be right to call it a plural. Of course, the point of the article still stands. Disclaimer: I don't speak Polish. I did learn some Czech though at some point (most of which I've forgotten).

FlorianZysset 3y ago

Unrelated but I had a weird experience navigating to this article on my IPhone: the music in my headset switched to call mode. I can reproduce that about 50% of the time. Is there something using the microphone somewhere? Feels really weird… 14 Pro Max with latest beta software

zengid 3y ago

Can I just rant for a second about how much I hate the whole `<starting-letter-of-a-word-><count-of-inner-letters><ending-letter-of-a-word>` trend that folks seem to love? This intentional sort of obfuscation makes it hard for juniors or students (the exact people who would be interested in an article like this), to engage in the material. The most egregious example is doing it for the word 'accessibility'!

Mordisquitos 3y ago
> <starting-letter-of-a-word-><count-of-inner-letters><ending-letter-of-a-word> Also known as <s73d> for short.