WeebWare / Ranobe-Honyaku

A novel translation platform.
MIT License
8 stars 2 forks source link

Multilingual Support #12

Open cloudiirain opened 8 years ago

cloudiirain commented 8 years ago

Just leaving this here because I can envision someone bringing this up eventually... and because it hasn't quite been discussed between all of us.

A super-comprehensive app would support multiple languages (as Baka-Tsuki supports multiple languages).

However I vote no on this.

Unless someone else volunteers to do everything related to multilingual support (models, translations, everything)... because it won't be me. >_____< This app is complex enough. I feel like we'd be decreasing the likelihood this will finish by adding this requirement.

Finishing something that's good in English is all I'm really hoping for right now. ;-;

scraeling commented 8 years ago

Maybe implement localization with this, and following the model suggested here should allow different languages without any extra work.

Maybe have tags for Volumes that show it's status (wip, completed, unedited), and the language that it's in.

cloudiirain commented 8 years ago

Localization usually addresses static content in an app (like the sidebar, navbar translations, etc).

We run into a more complicated modeling issue because we'll need to provide translations for series descriptions, volume titles... pretty much every field that an end-user can provide.

If we'd like to keep different translations of the same series related (link related series between languages the way it's currently done in Baka-Tsuki), a possible model to use is:

However, even if we choose to model this way, we need to think about UX. In the case where any translator wishes to add a new series, they somehow must go through a select-box of Series (not-language-specific) to ensure that they add it to the right place if it already exists in a different language (do we expect them to be able to read the other language?).

It's a complicated user experience. Could probably bypass this end-user UX complexity if we delegated the responsibility of figuring out whether a translation project exists in another language to mods.

Another model approach is to simply put a field on series. However, with this approach, it wouldn't be possible to link associated series (of different languages) together... at least, the normal way. Is it possible to do a self-to-self(many) relationship? lol We'd be modeling a network.

scraeling commented 8 years ago

I like the last approach. A record for a language is good since the series pages will be managed independently. Instead of more weird relationships, Series could just have an identifier field that's constant across different languages.

cloudiirain commented 8 years ago

Agreed. Though actually, having an identifier field that's constant across different languages is actually the same as the first approach (it's the same as having a foreign key one-to-many relationship to a table that has series (not-language-specific)).

The important difference though is that if you make this field optional, users/translators aren't forced to go through complicated UX when creating a new series, and somebody else can add it later. That solves the UX problem.

I guess you've changed my opinion about multilingual support. I'd be willing to do it. However, you have to ask at what is the priority of this requirement over everything else; and we have figure out what is a good time to do it.

byronvanstien commented 7 years ago

As for UI localisation; this'll be done through the settings that have yet to be added. Should be a simple implementation