This Time Self-Hosted
dark mode light mode Search

Do we need an i18n project?

So, people who follwo me since a long time knows I’m one of those people who likes to throw idea, make them start, and when they are mature enough to work by themselves find something else to start.

Although some people – me included – find this behaviour a bit strange and unsatisfing, up to now I think I was able to get some stuff working fine, like the —as-needed things that now most of the devs fix by themselves (although of course I always try to give a hand fixing the most difficult things).

Now, in the past days I wrote about translation and i18n in genre. I updated xine-lib and xine-ui in the tree with updated po files for Italian language, and as I said, I’ll wait patiently for other people to send me po files for other languages. As of tonight, I also created an Italian po file for gxine HEAD, that I sent to Darren for next version, it’s an original translation this time as there wasn’t one before.

I was thinking of translating VLC, but there are too many strings for myself alone, especially as I need to focus on my job still for a few days, and leave myself enough breath to take care of other stuff (as my felow developers already knew, in the past days I came very near to burn out because of people repeatedly asking me to find a solution to a problem that has no solution since… years – the infamous dependency range – without even reading the f..ine manual that would have already told them what they were asking me, and I’m not referring to users, but to devs – if they were users, it was fine by me).

Anyway, I was now reflecting that it would be interesting having a i18n project. Such a project could take care for instance of starting that increased UTF-8 support in Gentoo that was discussed more than one time in Gentoo before and nobody actually worked on. Yes, GDP and GWN has a lot of translators already that allwos to provide documentation and news in many differnet languages, but the general support for other languages is poor, starting from the metadata that misses lots of languages and it’s not always updated.

One of the problems is due to the fact that most of the GDP translators have no access to gentoo-x86 module, being doc developers. I think an i18n project should take care of this too.

Trying to summarise my thoughts now, this project would be in symbiosys with GDP and GWN, so that translators can be resource (if they want) for both; it would require gentoo-x86 committers to update metadata there, it would take care of making portage i18n capable (always if portage devs like the idea of course), and of updating the translations for the software in portage that’s not updated already. There are lot of stuff also Gentoo related that could use some i18n support, although some of it could be tricky a lot (think of pax-utils and portage-utils, that I don’t think vapier and solar are much intersted in making i18n-capable 🙂 ).

I should really try to find some other developers interested in this, and then start thinking of proposing this officially…

Comments 5
  1. I like the idea – maybe I should read up on metadata sometime soon, to see what I’m missing.Also, having Portage with i18n would be really sweet.

  2. Diego- suggestion, questioning whether other devs understand the dep range issue, should probably limit it to what the main complaint is- 380 daft atoms per ebuild in multiple packages when the actual valid atoms number around 20 is _broke_, pure and simple.Solution y’all use, while fugly, is fine- that said, it’s a bit misleading to paint people asking kde herd to fix their screwup in their dep/rdep generation resulting in 380 daft atoms as “they don’t understand the dep range issue”.

  3. Brian, you’re being a bit egocentric… the one not understanding the deprange issue wasn’t you.

  4. i love it, sign me up.proposals:- translate gentoo.org– translate man pages from portage and gentoolkit packages (Poles have them already :p)- translate everything in the tree that doesn’t change every day- fix groff to support UTF-8 (it has some ugly upstream bug not allowing that)- care for UTF-8 being a priority everywhere in Gentoo (maybe even setting up UTF-8 as a default encoding for freshly installed systems)What do you think? 🙂

  5. Rane, I totally agree :)Now that I heard a bit around, I think I’ll wait to see what the current discussion on -dev will do tonight and if it’s calm I’ll propose the i18n project there 🙂

Leave a Reply to FlameeyesCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.