Changes in "How to add a language"

[Nico Knoll]

Hey,

I think if you're a new user to Processwire it's really complicated to understand how to install a new language. I've got a couple of ideas how to optimize this:

Better Description: It would be important to show at least a link to a documentary (for example: https://processwire.com/api/multi-language-support/) and add some screenshots to it. So that you get a step by step tutorial. Additonally I would add a description to the "Language Translation field" on how to get the language files (link to: http://modules.processwire.com/categories/language-pack/)

Instant install: Another way to add languages could be the Textpattern way. But I'm not sure where to place this. In the module->new section? After clicking "add new" in the setup->languages page (that's the way I would prefer. And at the bottom a link "You're language doesn't exists? Create it now!")? Or somewhere else?

What do you think about this? And what are your experiences with adding a new language for the first time?

/ Nico

[Nico Knoll]

Edit:

Of course I would offer help in each of the points I've mentioned.

[Nico Knoll]

So I spent the last couple of hours in creating a module which imitates the Textpattern thing. Take a look.

LanguageInstantInstall.module

(You have to go to Setup -> Languages and add a new language). 

It's not completely finished (a function to update, etc. will follow) but it does what it has to do

What do you think?

/ nico

[netcarver]

Once this idea is proven and stabilised, would it be a core module candidate?

[apeisa]

I love it. Not at the position to test this (on holidays), but languages are not always natural languages. We have used pw language support for client specific manuals for example. Does this module also allow own languages?

[Nico Knoll]

At the bottom is a link which redirects you to the original "add page" page.

[renobird]

It's rare that I need multi-lang support, but I always liked the way it worked in Textpattern.

This looks great!

[netcarver]

I've looked through several of the language packs under the module repo but I can't find out where the language names shown in the image below are defined. Can anyone point me in the right direction?

Update: Are these fields derived from the module's class name by any chance?

Edited April 25, 2014 by netcarver

[netcarver]

Ok, I found that they are using the class name.
 
I think the Japanese and Chinese entries would be better shown in their own scripts - 日本語 [JS: \u65E5\u672C\u8A9E] and 中文(简体) [JS:\u4E2D\u6587(\u7B80\u4F53)] - respectively. Will PW or PHP choke on these if they were renamed at some point in the future? I'm not sure they will, as some of the languages are currently using unicode points from their own scripts.

[Nico Knoll]

Well that's not in my hands I guess. Probably it would be smart to curate the language pack section so the classname could be adjusted if it's not in the language.

Another thing I noticed while making this is that for example the vietnamese language says "vietnamese language pack" instead of only "vietnamese".

[Pete]

Nico - that'll be the age old problem with not being able to moderate these without knowing the language.

Perhaps there should be a simple way to suggest language changes if you're using anything but the default? Not sure how you'd do it though (if everyone on the planet had a Github account you could click a button somewhere in the admin and open an issue on Github for that language pack right there) but I guess there should be some text along the lines of "this language pack was created by a third party author. If you have any change requests you can contact them <here>".

Assuming it doesn't already say something like that of course - I've not needed to install one myself

[Nico Knoll]

I've added it to the modules section. Should be stable: http://modules.processwire.com/modules/language-instant-install/

[ryan]

Nico, tested out here and it works great. Thanks for making this. 

Just a few minor suggestions:

1. Your 'autoload' selector in getModuleInfo() works well, but might benefit from being more specific, like "template=admin, name=languages". 

2. Your hooks to ProcessPageType might also benefit from being more specific, i.e. ProcessLanguages rather than ProcessPageType. 

3. Rather than hard-coding the modules directory API key and base URL, you might want to pull it from the ProcessModule module, as it's possible for these things to change over time. Here's how you could grab them:

$data = $this->modules->getModuleConfigData('ProcessModule'); 
$apikey = isset($data['serviceKey']) ? $data['serviceKey'] : 'pw231';
$baseUrl = isset($data['serviceUrl']) ? $data['serviceUrl'] : 'http://modules.processwire.com/export-json/';

Note that above is falling back to hard coded values just in case of an older PW version... not sure that's necessary (I don't remember when these configuration values were added to the core). 

4. In your request to the modules directory web service, append "&category=language-pack" in the URL so that your results are limited only to language packs. Don't worry, you didn't miss this before, I just added the category filter option to the service.

5. Your module has downloadFile() and removeDir() methods that duplicate methods already available in the core. Basically, you can save yourself some code here if you want to. See /wire/core/Functions.php. 

6. Your module is using ZipArchive. You might find it saves time and code to use the core's built-in wireUnzipFile($file, $destination); method, also in /wire/core/Functions.php

7. In your module's getModuleInfo() method it refers to version 010. Change that to just 10. The leading 0 will make PHP think it's an octal number or something.

[Nico Knoll]

Hey, thanks for this great answer.

1. I added your addition.

2. It's ProcessLanguage (without s) (ProcessLanguages wouldn't work)

3. Included it.

4. Added it.

5. I'm not sure which function can replace downloadFile...

6. Integrated.

7. changed it and updated it to 1.0.0

[Soma]

5. It's in WireHttp WireHttp::download()

[Nico Knoll]

Ah okay, cool, I'll take a look.

[Nico Knoll]

I updated it.

[Manfred62]

Hi Nico, looks nice and does it's job.

What about a check if already any additional language exists? In my test installation I can additionally install de-de although german is already installed.

Hmm, but on the other side... most people will use this from the start in a fresh installation, so there's no problem.

BTW: typo on your blog-post. handeling --> handling

[Nico Knoll]

Yeah I think it's fine this way. Even if it allows double language installations - you could install a language manually two times, too.

[Torsten Baldes]

Great way to setup new languages!

ot: which theme do you use in your screenshots? thanks!

[Nico Knoll]

I'm testing a new theme by reno. Can't tell you more at the moment about it - but it will be released soon and it's going to be great

[Torsten Baldes]

another thing:

i just installed your module (v 0.0.8) and it keeps nagging me to update to 0.1.0. 

but when i do this, it's still on 0.0.8

[Nico Knoll]

Where do you got 0.0.8? On GitHub its 0.1.0 and in the modules section it's 0.1.0, too

[Torsten Baldes]

I installed via the ModuleManager Module.

EDIT:

i just took a look at the source and it says 0.1.0. But if i check for an update on the module settings screen, it says i'm on 0.8.0 and can update to 0.1.0

http://cl.ly/image/1t0Y2D2S0C0f

http://cl.ly/image/0t0c3r3F1f2L

Edited June 16, 2014 by tobaco

[Soma]

Once again I have to ask: Why is this a Process module?

There's nothing in there that makes this should be a Process module. All it will do is clutter the process select list on admin pages for no reason.

The version, as Ryan mentioned, should be 10 not 010. Leading zero's will make it read as octal, and octal 010 is 8.