For a current project, I’ve been struggling with my language files. They’re all JSON files, and will always fallback to English if translations aren’t available.

My problem is that when a new key is required, I use my english file by default. This leads to situations where my client wants to translate new keys to other languages, and I have to spend time looking at all files, figuring out which keys i haven’t added there.

Essentially I want to get to a point where I can give all the translation files to my client, and he returns them with the translated content.

What do you guys use for managing this? And how would you solve the situation i’ve found myself in.

  • DaleGribble88
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 year ago

    A trick the indie game development community has used for years is just a simple excel file. CSVs are the easiest to work with if you are unfamiliar. First column is the ID of the text that you can reference in code, and each column is a translation of that text. Get the initial translation in place, typically English, then email the excel file to anyone who ask to create as fan translation. Also, unless you are translating the Illiad, the extra memory use is negligible.

    • Faresh@lemmy.ml
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      1 year ago

      CSVs are the easiest to work with if you are unfamiliar

      A disadvantage with this is, if you ever want to collaborate with someone else using version control, it will increase the amount of merge conflicts, because multiple strings will be on the same line.

      • DaleGribble88
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 year ago

        True, but if there is a large project with many different collaborators, they’d need a more verbose system than a CSV file anyway. (And likely a more senior developer who knows how to handle situations like this.) My point is that excel files, and CSVs in particular, are easy to parse, easy to check for completeness, and easy to distribute to less technical people. Basically, while not optimal, they will just work.