Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wuischke]

Looks fine so far with Opera 9.26 and Safari 3.1 on Win 2003. I'll install IE7 later and I'll tell you if there are any problems.

Edit: It is OK on IE7, there's a small display error with the percentage, but otherwise it works.

[GeVauDan]

Thanks, i look that this afternoon !

[GeVauDan]

Looks fine so far with Opera 9.26 and Safari 3.1 on Win 2003. I'll install IE7 later and I'll tell you if there are any problems.

Edit: It is OK on IE7, there's a small display error with the percentage, but otherwise it works.

Corrected. Thx.

[GeVauDan]

Xhtml (strict) validation passed !
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fatwork.darknessmind.org%2FaMule%2Famule.php

Css (2.1) validation passed !
http://jigsaw.w3.org/css-validator/validator?profile=css21&warning=0&uri=http%3A%2F%2Fatwork.darknessmind.org%2FaMule%2F

[GeVauDan]

Do you love surprise ?
I purpose a new "logo"

Do you approve ?

[gulp]

seems a rabbit

[lfroen]

I have checked "litoral" template yesterday. My primary complain: language. Default is English. We may discuss options for localization support in amuleweb, but IMHO any template must have English version as a default, and localized version if author think it's needed.

[GeVauDan]

I have checked "litoral" template yesterday. My primary complain: language. Default is English. We may discuss options for localization support in amuleweb, but IMHO any template must have English version as a default, and localized version if author think it's needed.

Perhaps is it possible to integrate a translation through xml files.
Everybody can bring in their own language.
What do think developers?

[wuischke]

lfroen: Where did I miss something? It's quite possible that I overlooked a couple of strings when translating.

GeVauDan: It wouldn't be hard to integrate a translation on per-template base (assuming we establish a default "template template" we only had to do the work once), but this would be a client-side feature. (I prefer JSON over XML myself.) This is nice, because you can change the language on the fly, but it adds unnecessary complexity to the code (we need a container for every translatable string) and this would of course not work when JavaScript is not available.

A proper solution would be to do this on the server side, removing the complexity with only a little less flexibility. (You have to reload the xhtml pages when you change the language.)

Thinking about it, I actually like the idea, but I still lack the time [and a wardrobe and some chairs] to write some code for this.

[GeVauDan]

GeVauDan: It wouldn't be hard to integrate a translation on per-template base (assuming we establish a default "template template" we only had to do the work once), but this would be a client-side feature. (I prefer JSON over XML myself.) This is nice, because you can change the language on the fly, but it adds unnecessary complexity to the code (we need a container for every translatable string) and this would of course not work when JavaScript is not available.

A proper solution would be to do this on the server side, removing the complexity with only a little less flexibility. (You have to reload the xhtml pages when you change the language.)

Thinking about it, I actually like the idea, but I still lack the time [and a wardrobe and some chairs] to write some code for this.

   
The solution is simply to use a file type  ".ts" (xml formated) in a folder "translate" appointed in different languages (en-EN.ts, en-UK.ts, fr-FR.ts,...) and our famous config.inc . php to store this information.
Don't use javascript we reload the xhtml. We will not use function javascript to do that.

[lfroen]

Perhaps is it possible to integrate a translation through xml files.
Everybody can bring in their own language.
What do think developers?

The solution is simply to use a file type  ".ts" (xml formated) in a folder "translate" appointed in different languages (en-EN.ts, en-UK.ts, fr-FR.ts,...) and our famous config.inc . php to store this information.
Don't use javascript we reload the xhtml. We will not use function javascript to do that.

I have to admit that I have near zero practical knowledge about building web applications. I build amuleweb and it's php-like script to resemble (L)AMP as close as practically possible. What is "famous config.inc" you're talking about?
Now, someone please educate me - how one translates real site? Write HTML twice? Load strings from xml? If you need to add server side support for those thing - fell free to ask.

[wuischke]

We use gettext for translations, there's no reason to introduce another format. amuleweb is also a bit different from standard PHP and doesn't use its configuration structure.

I suggest implementing a new function to amuleweb PHP which would take care of the translation. This should be integrated with our standard translation procedure, i.e. using gettext.

Example:

Code: [Select]

<?php print _("Enter password"); ?>

[GeVauDan]

We use gettext for translations, there's no reason to introduce another format. amuleweb is also a bit different from standard PHP and doesn't use its configuration structure.

I suggest implementing a new function to amuleweb PHP which would take care of the translation. This should be integrated with our standard translation procedure, i.e. using gettext.

Example:

Code: [Select]

<?php print _("Enter password"); ?>

You're the brain It's ok for me

[GonoszTopi]

I suggest implementing a new function to amuleweb PHP which would take care of the translation. This should be integrated with our standard translation procedure, i.e. using gettext.

I welcome the idea as long as all the following functions are implemented at once (otherwise sooner or later someone will definiately ask for them in a Feature Request):
gettext(msgID)
gettext_noop(msgID)
ngettext(msgIDsingular, msgIDplural, count)

Amuleweb template translations should be independent of the main program's translations, so they can be supplied with the templates themselves. Maybe putting them into the amuleweb-<templatename> domain, and amuleweb should select the right textdomain together with the template.

On the other hand, amuleweb should also be able to access amule's translations, at least for the statistics tree, and for the log if we ever allow it.

[GeVauDan]

I suggest implementing a new function to amuleweb PHP which would take care of the translation. This should be integrated with our standard translation procedure, i.e. using gettext.

I welcome the idea as long as all the following functions are implemented at once (otherwise sooner or later someone will definiately ask for them in a Feature Request):
gettext(msgID)
gettext_noop(msgID)
ngettext(msgIDsingular, msgIDplural, count)

Amuleweb template translations should be independent of the main program's translations, so they can be supplied with the templates themselves. Maybe putting them into the amuleweb-<templatename> domain, and amuleweb should select the right textdomain together with the template.

On the other hand, amuleweb should also be able to access amule's translations, at least for the statistics tree, and for the log if we ever allow it.

Hi,
I agree the principle.
I wonder for some years about future of design applications (I make this work s1ince 10 years)
I think that we slide little by little towards a "all" xhtml/css to display a result of a query, for the portability from multi-platform, for the simplicity of evolution and update.

Finally, the future of aMule (and aMule Gui) is it not aMuleWeb?

The interoperability of the aMule kernel should it not steer it in the direction of amuleweb and thus to use more resource of aMuleWeb application (translation normalized by type .ts in the aMule gui)?