Comment form can't be translated

[Eddie]

Hi, I noticed, that although much of comment handling can be internationalized, at least comment form can't be (strings like "Add comment", "Save user info" etc.) I wonder why? This is not template specific and most of templates will use it. It wouldn't be very hard to add few variables ...

[Dkozikowski]

These are template specific.

templates/simple/comment_template.html

[Eddie]

But why? Every template (which contains comments) have some sort of this. It's strange that one part of comment system can be translated and the other can't.

[Dkozikowski]

Everything can be translated just not everything is contained within a language file.

[Eddie]

I thought that language file should contain phrases common for all (or most) templates. And comment form is surely *very* common component. I dare to say it is used in all templates.

90% of people use Pixelpost out of the box and do not use customized templates (moreover, there aren't all language versions of all templates).

[Dkozikowski]

There is no need for every variable to be within a language file.

The only variables Pixelpost places within the language file(s) are the ones that would require you to edit core pixelpost code if such a file never existed.

So, Pixelpost provides the users with a simple method of localizing the core pixelpost code via a language file and any other translations that are not contained within the core code will be found inside the template files.

[austriaka]

Eddie, you are right, most people use Pixelpost out of the box but most people using Pixelpost are native English ;-)

To be honest, people using Pixelpost are supposed to do some slight changes within their templates which come as basic examples for a good design and nothing more.
It is not difficult to change some text within a html file, it is not only "Add comment" or "Save user info" but also things like "browse", "about", "home" or "I will eventually put some information about myself or my photography here. For now, please just enjoy the photos."
So all static text blocks are to be changed within the templates and all phrases generated by Pixelpost can be changed within the language files.

[Eddie]

Eddie, you are right, most people use Pixelpost out of the box but most people using Pixelpost are native English ;-)
That's hard to prove ...

So all static text blocks are to be changed within the templates and all phrases generated by Pixelpost can be changed within the language files.
I understand this attitude, but I'm not sure it's the right way.

Of course, there is possible workaround. If I translate official templates (horizon and simple), would be possible to include them into official release? I looked into sources and there seems to be mechanism to use localized version of template.

[GeoS]

Of course, there is possible workaround. If I translate official templates (horizon and simple), would be possible to include them into official release? I looked into sources and there seems to be mechanism to use localized version of template.

The best would be to post it in Extend section of site as translated template files are not part of main distribution.

[Dennis]

I agree with GeoS on this one. Translated templates are not part of the distribution. As for the decision to use default English, this is because the main language on the internet is English.

[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]

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.


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]

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.

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/GettingStarted/AlternativeLanguage
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]

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.

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.

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).

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.

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]

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]

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.

[austriaka]

What I am thinking of is the same look-alike as now: Pixelpost should come with RSS, Comments, Languages and Paged Archive, with categories and tags and all what our users are used to use.
The difference should be behind the curtains: all those things should not be implemented in core code but in separate files, call them modules or addons, turned on by default, so migrating to 2.0 is as easy as now.
But all those things should have their own settings (like they have now) where they can be turned off if not needed (what they don't have now).

So for all users there will be no difference at all when using Pixelpost. But those users with special needs who don't care about categories or comments or languages or tags can really boost up their photoblogs speed by turning off what they are not using.
Everything shall remain in the database ready for use, but it is called only if really needed.

This is my imagination of Pixelpost 2.0 :-)

[Dennis]

Might I add that it is my imagination too?

[austriaka]

Ah, it is fine if the Dev-Team goes together here ;-)