Adding non-catkeys files (or links to them)

[humdingerb]

I was wondering if there could be links to other things that may need translating for an app. Like documentation or data files (recently I stumbled over the tips file for Tipster). Either as links back to the project's page (there could be several files tat need translation), or maybe even as uploaded ZIP archive (with a reasonable limit on size).

[KapiX]

1. I will not implement links to another files to translate for one simple reason: this defeats the whole purpose of this system. You'll end up managing files by hand, from multiple people again. This makes no sense.

2. Polyglot is a focused project (or at least I'd like it to be). I don't intend to replace, e.g. Pootle, which supports multiple formats and has a lot of features, simply because I don't have the manpower to do so. Adding new translation formats wouldn't even be that hard to do, but creates a precedent. That being said, I would add them if they were standard. Tipster uses a custom format. If I add one for Tipster, why not for other apps? Soon, you'll end up with a long list of formats used by one application each. Not my idea of maintanable. That gets us to...

3. From the existing translation file formats, I think Haiku catkeys are the easiest to implement. It's plain text, and very easy to parse. My suggestion therefore is to teach Tipster to read catkeys either by:

   • embedding tips in .h file and collecting them with other translations (not ideal, since to change the tips it needs a recompile)
   • writing a parser (maybe BCatalog can be helpful?)

I'm leaving this open, since it's a valid request, it's just not a valid example. If you believe my thinking is wrong, feel free to point it out :)

[humdingerb]

Your arguments are all reasonable and sound. :)

I never thought of Polyglot being actually used for translating those additional documents. I was only thinking that since it's so difficult to find any translators, it would be nice to point the few one did get ones hands on to additional documents of a project that would need translation.

Ideal would be if we had a maintained site like the user guide tool for 3rd party projects' "free text" translations. Without that, the dev will continue to have to handle several files from several people. But that's OK, I guess (esp. considering the indifference to translations among the Haiku users).

Maybe all this would be an argument to add a free text field in Polyglot's Meta data page after all. People could write something like:

Besides these GUI texts, Tipster needs translations for the tips themselves. Y

You can download them at https://github.com/HaikuArchives/Tipster/blob/master/tips/tips-en.txt and submit your translation at Tipster's issue tracker.

[KapiX]

I was thinking about an implementation of this recently. Here's what I came up with:

• Translation modules will get additional type: "file".
• The content will be uploaded as a file, so it can be anything: txt, odt, ods, png, etc.
• User will also upload a file + check whether the translation is complete.
• Uploading a new file by the developer will reset those checkmarks.
• Name will have a %lang% variable, so you still can download a package with everything.

Done this way it can later be used for screenshots, e.g. in user guide translations.

Let me know your thoughts.

[humdingerb]

That sounds like a nice way to go about it.

Name will have a %lang% variable, so you still can download a package with everything.

That means an uploaded English "ReadMe.html" gets automtically renamed to something like "deReadMe.html"? Or does the uploaded file has to be named e.g. "ReadMe%lang%.html"?

When the dev uploads an updated ReadMe file, will that reset all the already translated ReadMes back to that new English version? Updating a longer text like a ReadMe gets a bit tricky: simply uploading the updated ReadMe would result in having to do the translations again from scratch, even if there's just a few changes/additions. I guess we'll just advise in the "Help" page to just upload a diff of the old-vs-new English ReadMe. That'd leave the dev to puzzzle the parts together again, but I don't see a better solution. We'd need an instance of the userguide online tool for a more sophisticated approach... :)

[KapiX]

When the dev uploads an updated ReadMe file, will that reset all the already translated ReadMes back to that new English version?

No, the uploaded translations will stay the same, it's the translators responsibility to download the original translation and add new content. Only the "translated" indicator will change.

We'd need an instance of the userguide online tool for a more sophisticated approach... :)

It still wouldn't resolve issues with files like PNG or ODT. But yeah, that's the idea...

[humdingerb]

No, the uploaded translations will stay the same, it's the translators responsibility to download the original translation and add new content. Only the "translated" indicator will change.

OK. I don't have a better idea, but it's not optimal... :) Where does one download the original translation (or the original English file used for that translation)? Polyglot would have to keep older files (translations correlating with their English counterpart maybe using the md5 checksum of the English file). But I see how that makes things quite complicated...

Short of that big effort, we can only advise the translators to keep the English file around that they downloaded for their previous translation.

[KapiX]

Tipster format implemented in fa4962fa9c4ce276b66e05de3d19731fb81b7f63. Stay tuned for Java properties (HDS).

[KapiX]

Java properties done in dda21be56374be4ec375fea010f2586698624542 and c6f73beb8423c0cc1fbbc71448cea97aa48f83dc.