Jump to content

Progress on ProcessWire 2.2 and overview of multi-language support


ryan
 Share

Recommended Posts

Welcome to the forums Juan!

If I remember correctly Spanish language pack was more or less test case for Ryan and translation provided by Google. I am not 100% sure this is the case though, so you might wait for Ryan to confirm this before you start writing Spanish language pack from scratch :)

Link to comment
Share on other sites

Juan, we definitely need help with a real Spanish language pack. I don't speak Spanish and have no idea if the one I was working on is even remotely close to how it should be (I'm guessing it's not). I mainly started with a Spanish language pack because my wife speaks a little Spanish and I thought I could impress her. :biggrin: But I don't think she knows Spanish well enough to critique my language pack anyway. If you would be interested in making one, your help would be greatly appreciated! I'll be happy to send my latest Spanish language pack files over to you if it's helpful to use that as a starting point.

Thanks,

Ryan

Link to comment
Share on other sites

Hi Ryan, that would be great! So there's no need to start from scratch, thanks!

Thanks Jiserra, I've pasted the ZIP file for the Spanish translation at the URL below. This includes all the current translatable files, many of which don't yet have my fake Spanish translations. :) But I think this is still the best starting point. If your server supports it, you can just drag the ZIP file into files field when you create the Spanish language page. If not, then you'll have to extract the ZIP first and then drag the JSON files in as a group.

Link to comment
Share on other sites

I'm currently using translation in my front-end and I was thinking about the matter and how it really works. So if I decide to go and change a single letter or word in the default text code in a template, all translation originating from this phrase will get obsolete and need to be translated/entered again. Since it isn't key based translation, I'm not sure again, if it's still a good/the best choice when doing heavy multiple language site development. I feel it could get frustrating, when once all languages are in place and you spot a typo or decide to change the word or phrase, all languages need to be updated again as well even if it isn't needed.

What are your thoughts about this particular problem?

Link to comment
Share on other sites

One idea that came into my mind is to keep default language (the one that is defined in files) as something that is not actually directly used. So you would have 4 languages:

  • Default
  • English
  • German
  • Finnish

Guest user has English chosen instead of Default. If you need to change something. you don't edit the files, but you translate it from English files through admin.

This way it would be more like key based translation, but with one "free" language (if you leave English language empty, it will use defaults).

Link to comment
Share on other sites

Cool apeisa, just was thinking about this after writing the post. The translatable default text in templates could be used as keys like. Then having an _front-end_ english pack installed would do the trick. Acceptable solution I think. :)

Link to comment
Share on other sites

What are your thoughts about this particular problem?

This is an excellent question (as always). I've given a lot of thought to this a couple months ago. My thought is that the opposite would be a much bigger problem. There isn't any way that a machine could make a judgment call about whether a change in a translation is significant or not (as of February 2012), short of some very complex and creepy AI. :) Even more so given the diversity of communication possibilities among languages. A machine can't tell the difference between a spelling correction and a life-or-death medical instruction. The only safe thing to do is to consider the translation abandoned as soon as the original changes. Given the possibility of something important being in translated text, it's far better to present the text in its original form than in incorrect translated form. We've taken the lead from GetText on this, and I think it's the right way to go. Also want to add that both GetText and PW's built-in language parser are for static text that's not likely to change often, not dynamic text. Use the rest of ProcessWire for your dynamic text. :)

Link to comment
Share on other sites

  • 2 weeks later...

Guys, I've got a trouble with TinyMCE inputfield. When I use my translation file for it the field just stays textarea doesn't turn into TinyMCE. I put here the the translation file that causes trouble (changed file extension to .txt to allow upload). Thank you.

wire--modules--inputfield--inputfieldtinymce--inputfieldtinymce-module.txt

Link to comment
Share on other sites

Slkwrm, it looks like the problem is in the first translation. You just need to translate "en" to "ru". That text is yellow is a note for the translator about what that field is for, not text that needs to be translated. So if you replace the first translation with just "ru" it should start working.

Link to comment
Share on other sites

Short question to all creators of language packs: isn't it a good idea to store these packs on e.g. GitHub? It would simplify adding other peoples' improvements and changes.

I agree (and not just because mine are already on Github :P )

/Jasper

Link to comment
Share on other sites

I agree with the value of GitHub here. But GitHub is not necessarily a simple thing for everybody. I was intimated by it for a long time (and still am in some ways). So I don't want to have a GitHub requirement that would dissuade any would-be translators. Still, for those that are comfortable with it, it's hard to beat for this sort of thing.

Link to comment
Share on other sites

Hey Ryan i got this error while install Languages Support - Fields. I'm using latest commit.

I took a look at the code block where this comes from. Does it halt the installation? (I'm guessing not). Assuming it doesn't, and the error doesn't appear any more after this, then you should be able to safely ignore that message.

Link to comment
Share on other sites

Hey Ryan i got this error while install Languages Support - Fields. I'm using latest commit.

[b]Warning[/b]: Invalid argument supplied for foreach() in [b]/public_html/wire/modules/LanguageSupport/LanguageSupportFields.module[/b] on line [b]82[/b]

Hmm i just installed it on my fresh local install and can't reporduce this error.

Link to comment
Share on other sites

I took a look at the code block where this comes from. Does it halt the installation? (I'm guessing not). Assuming it doesn't, and the error doesn't appear any more after this, then you should be able to safely ignore that message.

The error is still there after the installation, but I cannot notice any strange behavior in pw...I will ignore...

Link to comment
Share on other sites

Wow, thank you guys for putting so much effort into this.. I'm just catching up on the discussion now! Since I work in Hong Kong and have clients in China, I'm going to give a shot into translating into simplified chinese (zh-CN)... but don't expect anything too soon, I don't know the language~

  • Like 1
Link to comment
Share on other sites

  • 5 months later...

Hi together,

i made my first steps with PW an as i know one of the first "problems" i had was the translation. I know that PW has a german translation but who the .... could i find that??!!

So i (and certainly much more others) would be VERY very happy when we could have a subpage for Languages in the Download-section?? Like the Post from Nico

- I would like to have an official translation (maybe in a subpoint of "Download" on this site), which is updated with every new release. So there would be a central point for the core translations.

The structure could be as follow:

Language Name - the percentage of finish - untranslated (count) - last change - a download link

somthing like this: https://translations.launchpad.net/roundcubemail/+translations

What do you guess??

  • Like 2
Link to comment
Share on other sites

Actually this page already exists in modules section :)http://modules.proce.../language-pack/

But if such questions arise it's clear that something can be improved. Maybe it's time to proclaim more explicitly that PW is multilingual. I found two places where it's mentioned on a homepage, but, honestly I would never think at the first glance that PW supports a dozen languages. Country flags or something noticeable placed on a homepege would be great and a dedicated link to language packs section too. What do you think, guys?

  • Like 2
Link to comment
Share on other sites

Oh cool !!

I see that pages the first time (ok i´m only 5 days on board) BUT yes !!! this site should - no MUST be linked at the download sektion!!

Thanks ;)

But this would be additional really cool

The structure could be as follow:

Language Name - the percentage of finish - untranslated (count) - last change - a download link

somthing like this: https://translations...l/ translations

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...