Comment form can't be translated

[Eddie]

It's sad, that Pixelpost will not have fully translated interface out of the box as most application do ...

Seems that all of you have same opinion, I won't troll on this topic any more.

[dakwegmo+]

Originally Posted by Eddie

That's hard to prove ...

It may be hard to prove, but it's a pretty safe assumption. Judging based on the activity in the International Forums vs. the rest of the forums, the overwhelming majority of PixelPost users speak English, whether it's their native language or not.

Originally Posted by Eddie

I understand this attitude, but I'm not sure it's the right way.

I don't know whether it's right either, but from a programming perspective it's a sound decision and certainly not wrong.

[Eddie]

Originally Posted by dakwegmo

It may be hard to prove, but it's a pretty safe assumption. Judging based on the activity in the International Forums vs. the rest of the forums, the overwhelming majority of PixelPost users speak English, whether it's their native language or not.

But difference between native speakers and nonnative speakers is IMHO quite big (especially when we talk about total count). According to wikipedia, there are approx. 309-380 million native english speakers. Let's say, 60% of them use internet (350 * 0.6 = 210). According to http://www.internetworldstats.com/stats.htm, estimated number of internet users is approx. 1.25*10^9. That gives us that native english speakers makes 1/6 of internet users.

But I don't want to talk about it, it's totally off topic.

Originally Posted by dakwegmo

I don't know whether it's right either, but from a programming perspective it's a sound decision and certainly not wrong.

As a programmer I understand it, but as an average user ...

But there's also thing that I don't understand even from programmer stand of view. Why official release could not include localized templates? We have localized frontend messages, admin, install, why not templates? There's even mechanism in Pixelpost for it. I'm aware of only one argument against it - size. Is Pixelpost really that big that it can't be little biggier?

[dakwegmo+]

Generally the best way to get something adopted as core code, is to write an addon or hack that will do what you want to do. If the dev team thinks it's a good idea they might consider adding it to the distro.

[Dennis+]

Well, here is food for thought: you might be correct that 1/6 of the internet population is a native English speaker. You can also consider that 8/10 of the internet population understands English. (interesting reading on the subject: http://www.cs.tut.fi/~jkorpela/lingua-franca.html)

So whether you like it or not, English is considered the standard language of the internet. By using English you will appeal to the largest chunk of the population.

Now on to why we don't include localized templates. Where would this end? Consider this: we, as the crew, have to maintain the code and the templates. If we add just a couple of localized templates for the major languages we have to maintain them. I speak my languages fairly well, but there is no way I can maintain a Chinese or Spanish template. I hear you thinking: why not ask someone to do it for you? Yeah, great thinking there and certainly a possibility.

However, consider the time we need to approach each template maintainer, process the changes and update the template. Not to mention the time we probably need when a user contacts us with suggested translations for a template, which we also have to relay to the maintainer.

If we look at the language files, as they exists in version 1.7, I can only say that it needs to be revised. The code is old, chunky, not flexible and certainly not easy to add new languages. But more important: we maintain the languages, but since we as a dev team don't speak all the languages we have to ask people to update the translations.

All in all this took about two months to collect all the translated files. As far as I'm concerned this isn't working. So what are we going to do? Well, one thought I have about it is to ship Pixelpost only with the English language. What will happen to the other languages? Good question: this is going to be the responsibility of the community. The community will maintain and make language packs.

This also has to be done for templates. Because I for one (and I reckon I don't stand alone on this) have no interest in a couple of dozen templates which I don't use.

Also the remark you made earlier concerning the standard phrases in a template could be a real disaster template-wise. You need to have tags for every phrase, which have to be replaced by the core code, making the code slower and certainly does not make making a template easier (because of all the tags you have to use). The fact that you can use HTML combined with some tags to get the dynamic output is a great thing IMHO.

Let's see what Pixelpost is: "Pixelpost is an open-source, standards-compliant, multi-lingual, fully <strong>extensible</strong> photoblog application for the web." Note the "extensible"? That is what it is all about. We provide the basic infrastructure for you to build on. This infrastructure is suited for probably 40-50% of the users, the other users wants to extend the possibilities.

Ow, and we're not alone here, Wordpress does it, MoveableType does it, Typo3 does it, Joomla does it and the list goes on and on and on.

One more thing: we're in the process of rewriting all the core code to a more cleaner and leaner version (we call this version 2). Every release we make is a push towards the version 2 release with more code optimization, cleanup and better structure. But remember: this is NOT our work, we do this for fun. (Yeah, hard to believe right?) So sometimes life just catches up on us and there are more important things to deal with.

[austriaka+]

one short thing to mention:
It is very easy to change a template file and again, people are supposed to do this. There is a great explanation written by Dennis how to do this for the template files in alternative language: http://www.pixelpost.org/docs/Gettin...nativeLanguage
Since this is language related the article is available in german too.

People are not supposed to change the language files, but of course they can do it.

So language files contain the stuff people are not likely to change while template files are thought to be changed by users.

When you run an update, your language file must be overwritten because there are always necessary changes when publishing a new release.
Template files can be kept and used after update as well, so people don't have to change anything there after upgrade.

[Eddie]

Originally Posted by Dennis

Well, here is food for thought: you might be correct that 1/6 of the internet population is a native English speaker. You can also consider that 8/10 of the internet population understands English. (interesting reading on the subject: http://www.cs.tut.fi/~jkorpela/lingua-franca.html)

So whether you like it or not, English is considered the standard language of the internet. By using English you will appeal to the largest chunk of the population.

There's no doubt that English is modern lingua franca. My only complaint is that other languages should not be ignored.

Originally Posted by Dennis

Now on to why we don't include localized templates. Where would this end? Consider this: we, as the crew, have to maintain the code and the templates. If we add just a couple of localized templates for the major languages we have to maintain them. I speak my languages fairly well, but there is no way I can maintain a Chinese or Spanish template. I hear you thinking: why not ask someone to do it for you? Yeah, great thinking there and certainly a possibility.

However, consider the time we need to approach each template maintainer, process the changes and update the template. Not to mention the time we probably need when a user contacts us with suggested translations for a template, which we also have to relay to the maintainer.

I understand it's not that easy. But as I understand, new release (1.X) is made approx. once a year. During beta stage (or when strings are considered frozen), somebody sends mail to language maintainer to update translation. If translation is not updated, it will not be included (although as you say, this is not so easy, but it's going to be fixed). Simple, effective. There's little work for you, developers. Just send one email and then accept translation updates. Once a year.

Originally Posted by Dennis

All in all this took about two months to collect all the translated files. As far as I'm concerned this isn't working. So what are we going to do? Well, one thought I have about it is to ship Pixelpost only with the English language. What will happen to the other languages? Good question: this is going to be the responsibility of the community. The community will maintain and make language packs.

This is also possible way. I plan to make (and maintain) independent package with fully translated czech interface (with little or no code changes).

Originally Posted by Dennis

This also has to be done for templates. Because I for one (and I reckon I don't stand alone on this) have no interest in a couple of dozen templates which I don't use.

I talk only about two templates included in official releases.

Originally Posted by Dennis

Also the remark you made earlier concerning the standard phrases in a template could be a real disaster template-wise. You need to have tags for every phrase, which have to be replaced by the core code, making the code slower and certainly does not make making a template easier (because of all the tags you have to use).

I talked about adding 10 - 20 more tags, IMHO there won't be big performance loss But if performance really matters, it would be easily compensated (e.g.) by replacing ereg_replace with str_replace where ereg_replace is not neccesary

[Dennis+]

Originally Posted by Eddie

There's no doubt that English is modern lingua franca. My only complaint is that other languages should not be ignored.

They are not. They are less important.

I understand it's not that easy. But as I understand, new release (1.X) is made approx. once a year. During beta stage (or when strings are considered frozen), somebody sends mail to language maintainer to update translation. If translation is not updated, it will not be included (although as you say, this is not so easy, but it's going to be fixed). Simple, effective. There's little work for you, developers. Just send one email and then accept translation updates. Once a year.

uhmn, no every 6 months (approximately) and this might become more in the future. So if we keep that scheme of 6 months we have to freeze after 4 months of development and not fix any code that requires changes to the language files. This is a major drawback and the reason we're behind with 1.7 (well that and the site issues).

This is also possible way. I plan to make (and maintain) independent package with fully translated czech interface (with little or no code changes).

Good initiative! We welcome this.

I talk only about two templates included in official releases.

times how many languages? Where do we draw the line?

I talked about adding 10 - 20 more tags, IMHO there won't be big performance loss But if performance really matters, it would be easily compensated (e.g.) by replacing ereg_replace with str_replace where ereg_replace is not neccesary

In the old code you would feel the performance. With the new setup this might become easier. But still we have to maintain backwardscompatibility (you know, for the average user....).

I really appreciate this discussion, since you're the first to mention it and perhaps we can find some common ground. (certainly not before 2.0 )

[austriaka+]

Hm, Eddie, I have the feeling this discussion is based on your own needs and demands on a photoblog. Be sure that there are many purposes why people set up a photoblog, not only show photos in a nice environment. This is the reason why there are so many templates outside and why there are so many addons available.
We have been asked quite often why we don't include this or that Addon into Pixelpost core code since everybody seems to use it and the actual language theme is the same discussion in the end.

Pixelpost is meant to provide a basic installation which just fits the minimum needs of everybody who wants to get photos published in the web on a daily scheme: An admin panel for uploading and listing photos and for doing some settings, not much more. And a front side where people can see one single photo and an archive.
Additional features like comments, tags or RSS were included in the past versions as well as multilanguage capability because there was the demand of a big majority of the users.
But everything else will and should stay an optional extension since not everybody might need it. I even think one step further, reducing Pixelpost to the absolute minimum in 2.0 basic installation and doing everything else as Addon (tags, categories, languages, RSS and even comments) which come with the installation package but can be turned off if not needed.

I think the future Pixelpost will be some sort of modular concept: the core code which everybody needs and modules for extending it up to personal needs. And a lot of Addons and Templates provided by our eager users to extend Pixelpost to whatever you want (but I am afraid it will never take photos for you ;-)).

[Eddie]

Originally Posted by austriaka

Hm, Eddie, I have the feeling this discussion is based on your own needs and demands on a photoblog.

I'm biased and I admit it

In general I agree with your post, I like this kind of application (Miranda, Foobar2000) and it's certainly good and solid application design. Problem with this type of application is that it's quite hard to make it usable (as you have to download a lot of plugins, configure them etc.).

Good compromise is to distribute core for experienced users and then some kind of "power pack" which is preconfigured for most beginners.