Patchwork: Agglutinative languages not easily supported by design

[ppseprus]

Premise

While in English, one writes _xy subscribed to something_, the same will be _xy felíratkozott valamire_ in Hungarian. Note the bold parts.

And this is further complicated by the fact that to different words, such a language often _agglutinates_ different word parts.
_valamire_ but _dologra_ (to something, to (a) thing)

Problem

The current JSON structure only allows translations to such languages that are not really native-like.

[christianbundy]

Thanks for noting this problem. I'm not very familiar, how do other projects work around this sort of problem? Is there a translation-friendly way to structure sentences, or is your suggestion to change the current translation implementation?

[ppseprus]

Well, to be honest, Im usually not into translating things to Hungarian. This is the first time I thought it would be useful, as a community service. So.. I don't have much experience in it either.
For now, I just wanted to note the issue.
I will research it, because I've already translated what I could... Will get back to you on it! : )

[ppseprus]

Well.. I have one thing. Some lines are static while others include the "context" as argument. If there's anything around the text, that should always be part of the language file as _%s_ argument. This way, the translators are provided with a little bit more freedom.
Probably will make a PR for this one :P

[mmckegg]

Yeah, would love to redo all the strings with %s, however with the current i18n implementation it makes is impossible to have the substitutions be styled or hyperlinks (which we need, e.g. linking to a user's profile).

The way forward is to solve the formatting/hyperlink issue (maybe with a different [mutant compatible] i18n lib), and then write some kind of script that goes through all of the existing translations and reformats them with the new translations.

[ppseprus]

I have a half-finished correction on this. I will try to finish it up and open a PR. I actually found other problems too, like a label is reused at different places. The problem with this is that in english, they are the same, however, e.g. in Hungarian, they should be translated differently... So... Im consolidating and even adding new labels.

[ento]

I started a Japanese translation and came across this issue. @ppseprus do you have time to push up a PR, even if it's not completely finished? I could pick off fixing some of the string usages based on your work.

[ppseprus]

Hey @ento! Sure! I'm a bit busy, but will try to make time for this in the next 2-3 days! : )

[ento]

@ppseprus I just realized we won't be able to collaborate within this repo easily since I don't have write access (if I had, I could push commits to your branch directly once there's a PR that allows it). So: opening a PR isn't really necessary and just pushing up a branch to your repo will be sufficient. I could either make a PR to your branch in your repo, or make smaller PRs to this repo by cherry-picking some of your commits (if you don't mind) and adding my own commits.

[gergelypolonkai]

This is a really hard problem, and even English has something similar: a [insert word here] vs. an [insert word here]. I donʼt think there is a working solution for this.

There are workarounds like “X feliratkozott a(z) Y cimkére” (“X subscribed to tag Y” literally), but that might require extra work on the English version, too.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?