[Mageia-i18n] Some problems with website

[Filip Komar]

@Romain mostly ;)
> first a big, huge thank you again for diving into this! It's really
> great to see more people grasping this Web site. :)
Thanks Romain. Nice to read that ;). All I did was some scratches on the
surface and mainly those were my itches ;). I'll gladly try some more but
since for now I'm still alone in Slovenian i18n team we'll see. Php is
really interesting hobby for me and I voluntary admin one self-recovery
website including their member page and some data input and pdf generation
from database. Great creative and learning experience but it also take a
lot of my time. Due to serious medical condition of my knee I had more time
for 4 months from the middle of February. Now when I'm in the middle of 2
week leave I do some practice ;). I'll focus on help for our team
especially on lang system conversion. I can do some work or tests for you
in the long run but I really can't promise much since all this described
above take a lot of my time. I'm sure that you understand my position and
priorities.


>> 1. Why $post argument in function _t [4] append space by default? It
looks a
>> bit strange on some pages as on few strings there is sometimes comma
after
>> translated word. For example in community page.
>
> Indeed. I did it too fast. The problem I used to have was, when doing so:
>
>  _e('some string.');
>  _h('again %s!', array('here'), 'h1');
>  _e('some other string.');
>
> To have no space after the dots.
I'm sorry I'm afraid that I failed to fully understand the logic of
functions _e, _h, _t and _d and it's chain loading without a test server on
my PC. Maybe I'll setup another one ;). This is maybe a oversimplification
but for easier understanding here is what I see now. Difference between _e
and _h is that last one adds tags but they both call _t which all it does
is returns translated string from _d and add space or something else. I
looks to me that you added function _t just for that problem of added
space. Can _t and _d be merged? Both _e and _h can take arrays as argument
but I think that this won't be needed when transition to lang system is
fully finished. Is there anything missing or wrong with that (mine)
understanding? Right now I'm unsure if I can be any assistance in this.


> I can improve the pa2lang.php script.
To my experience it works fine. As I recall there weren't any negative
reports from others either.

> As for extract2lang, I would suggest to use Mozilla's tools instead as
they are likely more mature.
I didn't try to use extract2lang yet so no feedback from my side yet.
Mozilla's tools are unknown to me. Can you or anyone give me a link to
learn about them as I couldn't find it.

> fr/thanks and en/for are relics. You can remove them. */faq too
Done [1]. They were all empty.

> Although en/migrate may be removed as well.
Done [1]. No content on page anyway.

> As for the redirections, I'm working on a small dispatcher ...
Great.


>> It would be nice and fair if such old translations
>> would be visible in our report page.
>
> That is? (not sure I got the idea)
The idea is about small improvement in report.php. Similar as function
get_other_langs() checks for files in subdirectory of /langs/ there would
be a new function which would search for *.php and *.html files in root
language directories like /cs/ and all other languages of course.

if (file_exists($langF)) {
    ...
} else {
    if (non_lang_translation_php_file_exists()) {
        sprintf('<td class="old_translation_present (background:
yellow;)">Old translation php file present. Would you like to <a
href="missing.php?s=%s&l=%s">convert it</a> to new system?</td>' ...
    } else {
        sprintf('<td class="missing">add</td>' ...
    }
}

I hope that I explained my idea a bit better.

Thanks for your time reading this,
Filip.

[1] http://svnweb.mageia.org/web?view=revision&revision=1532
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/mageia-i18n/attachments/20120730/86de1198/attachment.html>