problem: blockrazor is not multilingual

[gsovereignty]

Problem: blockrazor is not multilingual

Solution: not sure, hoping for a discussion ;)

[anbud]

TAPi18n, a key based translation engine for meteor, could be a perfect solution here. It's simple to use and implement, it uses json or yaml for translation files.

I'm claiming this one when we decide what solution we'll use. :)

[gsovereignty]

Yeah that's probably the best way to go. Feel like doing it?

[AshHimself]

Worth breaking this up by pages ? Fair bit of hard coding right ?

On Sat, 1 Sep 2018 at 8:36 pm, Gareth Hayes notifications@github.com wrote:

Yeah that's probably the best way to go. Feel like doing it?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Blockrazor/blockrazor/issues/1818#issuecomment-417856801, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJEynBfXEIcIWUs64Y9Yd-bfquBef1Uks5uWn9EgaJpZM4WWCs4 .

[gsovereignty]

Yeah, good idea. I guess do one page first, e.g. "currency detail page is not multilingual" and use that as a standard for people to follow when doing other pages.

[anbud]

Sure thing, I'll implement it on a couple of pages.

[anbud]

Implementation of TAPi18n on the first couple of pages (landing, home, and shared components (header, footer, ...)) is done in #1819.

As you can see, translation files have to be in the i18n folder and they have to have the .i18n.json or .i18n.yaml extension for JSON and YAML respectively. Before the extension is the language code (en for English, fr for French, sr for Serbian and so on). (e.g. valid translation file name is home.en.i18n.json)

When you change strings to translation keys in templates, make sure that you scope translation keys properly (you can see my scoping in this PR) as you can run into issues if translation keys happen to be the same in multiple files. Using translations is as easy as using {{_ "translation_key"}} in templates. Although it's not very recommended, you can also use HTML in translation strings, but then you have to use three { ({{{_ "translation_key"}}}) in templates.

[anbud]

I believe that individual folders in /imports/ui/pages are a nice way to divide the multilingual conversion work. So, here's the list of what needs to be converted to TAPi18n:

• [x] landingpage
• [x] returnedCurrencies
• [x] moderator
• [x] currencyDetail
• [x] problems
• [x] auctions
• [x] codebase
• [x] communities
• [x] ratings
• [x] bounties
• [x] addHashpower
• [x] allHashaverage
• [x] allHashpower
• [x] faq
• [x] addCoin
• [x] editProfile
• [x] signin
• [x] signup
• [x] userPendingCurrencies
• [x] userProfile
• [x] activityLog
• [x] compareCurrencies
• [x] developers
• [x] distribution
• [x] exchanges
• [x] prices
• [x] suspended
• [x] transactions
• [x] wallet

Please make sure to convert any literal strings in .js files as well. You can use TAPi18n.__('key') there. Feel free to open a new issue (problem: x is not multilingual, e.g. #1821) when you start working on a given section and mark it here so others know it's taken. :)

[anbud]

@gazhayes, I believe this one is concluded, everything has been converted to TAPi18n. Feel free to close. :)