New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow switching language using lang url param #219
Conversation
Currently if a language is selected and i18n messages are missing the i18n code will be displayed instead If no language is passed a default of de is used.
This approach seems a bit hacky to me. Can't we take the remaining strings from the |
I was actually also thinking about something like what @jakobw suggested. I am not sure which solution will be nicer though. |
Well assuming not all browsers have JS we would probably always went a landing page which also renders useful content without JS. Fixing the landing page for non JS browsers is also something that should be done in my opinion saying that the site requires JS, right now it just half loads and doesn't work. |
That's a good point. There should be some kind of i18n-enabled noscript info. |
This branch is pushing towards the i18n not only being handeled by JS thus it makes sense to split the files out of the js dir. For easy adding of more languages the i18n json file has also been split into 1 per language.
My current thoughts for the large blocks of text on the landing page are that they could be split out into separate html files which could then each be localized? ./i18n/html/de/about.html The text on feedback is probably small enough to keep in the json file but the about and legal sections just seems a bit insane. |
After this the only js strings not in the i18n files are the internal errors that afaik will only go to the JS console and will not be presented to users.
This makes the feedback form pass through the language to the email backend so that localized errors and thanks messages can be send back to the frontend.
As far as I can tell this PR now covers i18n for all strings (except internal exception messages which are not really user facing). |
Ohh, that looks really cool now! |
If I remember correctly I also suggested putting large blocks of texts in files so they can be translated but somehow after we discussed this we concluded that it would be better to have them all in one file (split large texts into paragraphs) to make it easier to just give it to people for translation. I think this looks pretty good though and it's super nice that we can even have a translated message for people who don't have JS activated. What do @manicki and @tobijat think? :) |
if( !file_exists( $langFile ) ) { | ||
$langFile = __DIR__ . '/../../../i18n/de/i18n.json'; | ||
} | ||
$this->i18n = json_decode( file_get_contents( $langFile ), true ); | ||
|
||
if ( $this->requestValid( $app['request'] ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also be $this->requestValid( $request )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
} | ||
|
||
// Also replace html snippets | ||
$htmlFiles = array( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can haz new array []
syntax!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do everywhere! :)
Yes the longer texts in files do seem quite manageable, however I feel that I should take a look at legal.html and remove the tracking switch from there.... I guess the switch itself should remain in the main html file and the strings around there should head to the i18n.json file |
|
||
module.exports = new Polyglot( { phrases: i18n[ 'de' ] } ); | ||
var getParam = function getUrlParameter( sParam ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought JS would have a built-in thing to deal with URLs but google didn't spit anything out :/
This means the order of the replacements does not matter. Before if the two keys below got replaced in this order bad things would happen. index.foo-bar index.foo-bar-1
"index": { | ||
"title": "Lizenzhinweisgenerator", | ||
"description": "Lizenzhinweise für Bilder aus Wikipedia und Wikimedia Commons", | ||
"no-script": "Sie müssen JavaScript zur Nutzung dieser Website aktiviert.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am guessing this is not entirely correct Kraut speak, although it contains all words I'd expect: "müssen", "Javascript", "aktiviert" :)
Let's have @jakobw and @WMDE-Fisch suggest something better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, close enough though. Something like "Zur Nutzung dieser Webseite muss JavaScript aktiviert sein." would be better.
Looks really nice! So basically it will be ready to go after updating one translation to what Jakob suggested. |
+:100: |
Currently if a language is selected and i18n messages
are missing the i18n code will be displayed instead