Language system

[Sobak]

While focusing on translating pre-even-alpha stage code into 100 languages doesn't make sense, we should already determine requirements for our translations system.

• type:
  • key-based (e.g. Laravel's Localization facade)
  • original-content-based (e.g. gettext)
• language file format - personally I think only three options make sense:
  • INI - easy to read, write and parse
  • Gettext - there is a whole bunch tools (including online tools) for *.po and *.mo files
  • PHP - just more powerful in our case (but do we need that power?), most efficient as well
• language system
  • ext/gettext - no-go for me - requires hacks to avoid its own design decisions (which just don't fit web applications)
  • Symfony Translation component - great piece of code but in case of PHP/INI format might be an overkill
  • our very own solution

Personally, I would prefer gettext+symfony translation or just PHP files with simple wrapper (for pluralization and fallback language) - it all depends on the real performance impact.

[Albert221]

Good idea.

I would prefer key-based translations in YAML or PHP file (with greater emphasis on YAML because of its simplicity and redability) with our own solution for managment of their display in website.

I would not prefer ext/gettext because of the way they are generated. It is not just opening the file, translating the values and saving it with different language symbol in name, but it forces to use 3rd party programs to generate .mo files and that would be big lose in terms of translation made by community, because it needs more effort which is equal to less contributors.

What is the reason of your decission?

[Sobak]

I would prefer key-based translations in YAML or PHP file (with greater emphasis on YAML because of its simplicity and redability) with our own solution for managment of their display in website.

Wrt. to prefering PHP over Yaml: PHP is not that less readable than Yaml (we can use shortened array syntax), but what's more important it's native - there is no need to parse, to invent strange eval-like syntax in case we would need some dynamic parts (I doubt we would, but if so, PHP has it out of the box).

As per creating and maintaining gettext translations - there are plenty of programs, including free web services integrating with GitHub so it's not a real blocker. I just think it might be an overkill (in terms of both workflow and performance) - that's why I prefer just good old plain PHP files.

I wouldn't have anything against Symfony Translation component, but if we want to reinvent somehow lighter solution I have one - don't really remember where but it's a matter of adding pluralization support to it.

[Albert221]

It makes sense.

What about PHP array files for key-based translations managed by some custom written or small open source library? For simplicity sake.

[soanvig]

Maybe i18n? Dynamic parts are not ment to be interpreted in localization file, but in script itself. Localization file only handles displaying text and variables provided as argument to function. And i18n is common practice.

[Albert221]

@soanvig yes, definitely, i18n is I think the only reasonable way to achieve translations in FromSelect.