1

Topic: Addons translation

Since we just had some new levelsets in, what do you think about making them translatable somehow?

We would need some form of repository and textdomain handling for this.

2

Re: Addons translation

I'm going to shuffle this one over to the Other Contributions subforum as it feels that that's the best place for it to live.

Cheese
==========
cheesetalks.net

3

Re: Addons translation

Nice idea, but I am not sure about how to achieve this. Maybe our developers can enlighten us about how gettext works and how it is possible to split translations into separate files.

~DEV

4

Re: Addons translation

It's probably doable, using separate domains for sets and courses and packaging them as game data.

Don't know how I feel about having a translation repository for non-official stuff, though. If it's worth translating, wouldn't it make sense to make it official instead? How would packaging and distribution work, also?

5 (edited by GunChleoc 2014-02-18 19:39:49)

Re: Addons translation

Maybe the best way to go about it would be to have a separate locale directory for each levelset. This way, a separate po/mo file could come with each levelset.

Battle for Wesnoth and Widelands both have some working scripts for stuff like that, maybe you could take some code from there to adapt. The latest improvements for Widelands aren't in trunk yet though, because we're waiting for afte the next release with that.

How much stuff we make official would depend on if you wish to limit the download size I guess. In any case, it makes translating of big software projects less scary when stuff is split into separate po files.

6

Re: Addons translation

Thanks, but I don't really need technical advice. I'm asking how do you imagine providing translations for non-official content? How would it work? Somebody posts their unofficial untranslated level set and then what?

7

Re: Addons translation

It's a matter of providing the po files to the translators, is it not? Which is why we would need some form of repository rather than just forum posts. Maybe a second repository in git for addon levels? They could also be uploaded to Transifex and linked to the source file for automatic .pot updates.

That's the ideal world, of course. We could also have some form of "call for translations" thread where authors post their levels to be translated, but that would be harder to keep organised.

The reason I pointed to Wesnoth is this - lots of add-ons to translate (anything below wesnoth-utbs) are listed on that page.

8

Re: Addons translation

parasti wrote:

I'm asking how do you imagine providing translations for non-official content? How would it work?

Translations of single levelsets would come along with the zip package.

Somebody posts their unofficial untranslated level set and then what?

Not everyone would be willing to translate their own level intros, but that's fine. Untranslated stuff just stays untranslated.

~DEV

9

Re: Addons translation

GunChleoc wrote:

It's a matter of providing the po files to the translators, is it not?

I'm just really confused on the concept of an official translation effort for non-official content. Ideally, if the content is good, it should be made "official" instead, shouldn't it? Does Wesnoth have any criteria for their "unofficial" packages that are available for translation?

10

Re: Addons translation

This is how it works in Wesnoth: http://wiki.wesnoth.org/WesCamp

Wesnoth addon authors define themselves if they want their stuff translated, and then it's a matter of configuring everything properly. Their textdomain then automatically gets added to the list as sonn as they upload the add-on to the server.

Addons are on the bottom of the list, so translators know what is official and what isn't.

11

Re: Addons translation

parasti wrote:

Ideally, if the content is good, it should be made "official" instead.

This is something we must consider revising. I will briefly quote something you said about a year ago, which I heartily agree with...

parasti in 2012 wrote:

I really kind of want to get rid of the "holy grail" status of something being included in a Neverball release. I want a game that doesn't grow infinitely in download size. I want high-quality levels in the level repository that are "part of Neverball" in every sense except that they are not part of the initial download. Stuff like that.

Do we seriously need to label stuff as 'official'? I don't consider my levels enough polished to be made official and yet I would like people to play it and I dream of a workflow that allows our users to enjoy the so-called 'unofficial content' the same way they enjoy official levels.

Now... translations of level intros may or may not be considered essential to achieve this. After all, among our official sets we actually have some intros in french that we chose not to translate, and this never happened to be a problem. Then, untranslated content is still quite enjoyable.

What we need to change, though, is the way we categorize this content. I would like a system that encourages even those who aren't part of the Nevercorner (or those who have even never heard of it) to use unofficial content.

~DEV

12

Re: Addons translation

ht-never wrote:

This is something we must consider revising

I think everyone agrees that a level (addon) repository would be awesome. But the initiative to make it a reality will have to come from someone else, not me.

13

Re: Addons translation

parasti wrote:

I think everyone agrees that a level (addon) repository would be awesome. But the initiative to make it a reality will have to come from someone else, not me.

I didn't mean to say that we should put all our efforts in such a project. I am just giving you a reason to support GunChleoc's suggestion: Implementing translations of unofficial content would change how the end-user perceives the unofficial content.

~DEV

14

Re: Addons translation

Would it, really? Realistically, without a repository and a centralized translation effort, custom levelsets would have around 1-3 translations provided by mappers themselves, compared to the around 20 translations that Neverball has. That doesn't seem very valuable / perception changing to me.

15

Re: Addons translation

The best thing really would be a repository. It is kinda hard to separate packages with our current file structure though. We would need a mods or levelsets directory with a separate subdirectory for each levelset, or am I wrong with this assumption?

I will try upgrading my system again when the next Ubuntu LTS release comes out in April. I will then try to compile again and maybe I can do a bit of coding. I can't promise that this won't exceed my skills though.

16

Re: Addons translation

GunChleoc wrote:

It is kinda hard to separate packages with our current file structure though. We would need a mods or levelsets directory with a separate subdirectory for each levelset, or am I wrong with this assumption?

I don't know what you'd be trying to solve with that.

17

Re: Addons translation

I was thinking if we want to link addons translations to Transifex for automatic updates, they can't be zipped. There is also less potential for file name conflicts with custom images etc. if every levelset has its own separate directory.

18

Re: Addons translation

Ah, gotcha. I didn't realize you're talking source control. I am pretty sure that is already doable, thanks to PhysicsFS, although it's a bit of a hack: just add a .zip extension to a directory placed where ever you would place a ZIP file normally, either in the config directory or in the data directory.

Also, damn, I forgot that gettext can't read ZIP files. When we distribute the addons, we'll have to do something nasty like extract message catalogs to ~/.neverball before we'll be able to read them.

19

Re: Addons translation

If I am not wrong, PFS treats Zips as virtual extensions of the /data folder. How do I add an extension of the /locale folder?

~DEV

20

Re: Addons translation

That's not what we're talking about. Addon translations will still need code changes.

21

Re: Addons translation

If you decided to arbitrarily place the /locale folder as /data/locale, would something change? (Yes, a few code changes are needed, at least to let Neverball know where the folder that used to be at /locale is)

~DEV

22

Re: Addons translation

I don't understand what you would accomplish with that. Yes, at some point the locale data will have to be moved to be inside the Neverball filesystem. But that is only a small, insignificant portion of the work that would need to be done.

23

Re: Addons translation

parasti wrote:

But that is only a small, insignificant portion of the work that would need to be done.

This is what I was asking. I wanted to know whether it was possible to easily move it inside the Neverball filesystem and apparently your answer is 'yes', which I am glad to know.

~DEV

24

Re: Addons translation

I don't think you realize that gettext accesses its message catalogs very differently from how Neverball accesses its filesystem. Neverball uses a virtual filesystem that supports directories and ZIP files with a layered structure and file lookups. gettext just reads uncompressed files from a specified directory. gettext can't support or use a lot of the features that the VFS provides. For example, it is explicitly possible to ZIP up the data directory contents and make a data-20140224.zip and distribute the data that way. BUT, if locale data was also distributed that way, gettext would not be able to read it. So, yes, moving the directory is "easy", but serves no purpose and breaks a bunch of things - unless additional code changes are implemented.

25 (edited by ht-never 2014-02-24 18:37:06)

Re: Addons translation

parasti wrote:

I don't think you realize that gettext accesses its message catalogs very differently from how Neverball accesses its filesystem.

I get it.

gettext just reads uncompressed files from a specified directory [...] So, yes, moving the directory is "easy", but breaks a bunch of things - unless additional code changes are implemented.

Now, that's the problem: moving the folder breaks a bunch of things unless code changes are implemented.

Now... I am quite unprepared in programming, so...
1. What additional coding would be needed?
2. Does it take a lot of effort to be implemented?
3. Are you inclined to implement this kind of changes or would you consider it a waste of time?

~DEV