search

olivierperez / o80-i18n

PHP i18n (internationalization) system.
Apache License 2.0
12 stars 5 forks source link

why o80-i18n? #4

Closed drzraf closed 8 years ago

drzraf commented 8 years ago

What advantage has o80-i18n over gettext? No tool out there supports this new format, what issue does it intend to solve?

olivierperez commented 8 years ago

Hi, glade to see you're interested by o80-i18n.

There was 2 things that make me develop o80-i18n. The first one, I was developing on a Windows computer and I wasn't able to see translations. The second one, the need to compile the dictionnary with gettext was awful, especially when developing.

On the project I work, no one wanted to contribute to translations. Since we moved to o80-i18n, contributors fixed some dictionnary. We already add 1 lang and we are adding a new one.

To finish, the format is not realy realy new... For now o80-i18n can work with JSON or INI, they are NOT new formats.

Stay tuned if you need more explanation.

drzraf commented 8 years ago

Although it'd be worth it, I'm not going to take the defense of gettext. But I've a strong feeling of NIH (gettext does work on windows, and compilation can be made easy with a simple makefile or a composer rule)

Many projects using gettext have a load of i18n contributors. msgmerge & co help getting multiple contributors participating using their preferred software. And various community translation-projects (eg: transifex & co) are based on gettext (ie: permit importing/exporting from/to gettext).

About framadate, I'd rather point you to: https://git.renater.fr/gitweb/?p=studs.git;a=log;h=refs/heads/pdo_i18n See commit contains revision=172, revision=175, revision=176 and revision=177 = there was a reason to switch from a custom home-made i18n system, to a well-known standard i18n system.

Since Simon Leblanc didn't kept history when going git, you could not have known that. I just tried to fix this.

I hope you may want to take the time to understand gettext() and the benefits it brings.

bagage commented 8 years ago

I strongly agree with @drzraf: gettext is not perfect (at all), but at least there is a strong ecosystem around it. o80-i18n is working on the developer side, but there are tons of other issues:

I believe this is now too late to get back to gettext?

drzraf commented 8 years ago

Updating the gitweb link: https://sourcesup.renater.fr/plugins/scmgit/cgi-bin/gitweb.cgi?p=studs.git;a=log;h=refs/heads/pdo_i18n

Back in 2010 I had written a PHP-script in order to migrate automatically the strings in Studs from the home-made translation-system to the gettext syntax: https://sourcesup.renater.fr/plugins/scmgit/cgi-bin/gitweb.cgi?p=studs.git;a=commitdiff;h=88072b2ad659bef7785ff722c456e9cc0405d07d

Those who don't understand UNIX are condemned ...

well, you know

olivierperez commented 8 years ago

Hi, we are not discussing on the right project. This one is just a library to use json-based i18n in PHP. If you want to talk about Framadate, there is an open repository : https://framagit.org/framasoft/framadate/

By the way, possible or not, I don't want to go back to gettext :smile:

drzraf commented 8 years ago

https://framagit.org/framasoft/framadate/issues/193