Untranslatable strings

[wl-zocker]

In the new tooltip for dismantling and upgrading a building, the strings "Returns: " and "Construction costs: " seem to be untranslatable (they appear in English and on Launchpad, I could not find them).

Furthermore, in the statistics of a constructionsite, the word "built" is not translated neither. (see attached screenshots)

[Shevonar (shevonar)]

The strings are translatable, the translations strings have just not been updated yet. This is usually done every few weeks and not for every single string. Maybe someone likes to rebuild the translation dictionary, but I think this can be set to invalid though.

[SirVer (sirver)]

I updated the catalogues, the new strings should show up on launchpad within the hour.

[Hans Joachim Desserud (hjd)]

As people probably have noticed, the new strings are now available on Launchpad.

(I find it a bit annoying the strings have to be manually updated whenever something is changed or added. On the other hand, running the script to create new .pot-files would at least replace the POT-Creation-Date which means we won't get an empty diff if no strings change, so it doesn't look easy to automate either. )

Btw, while I can see why it was marked as invalid, the real issue here is a request to generate new translation templates. Now that this has been done, and the strings appear on Launchpad, I think this can be set to fix committed.

[SirVer (sirver)]

I you argue this way, it is even fix released, since the strings are now on launchpad already, right?

[Tino (tino79)]

I don't agree, SirVir. even now it shouln't be "Fix committed" because the translations need to be merged from branch to the trunk.

1. New code is written which contains translatable strings. A bug should be only filed, when the string is not marked translatable => Bug confirmed
2. Some dev creates new translation catalogs => Bug triaged / In Progress
3. Someone translates it on launchpad => In Progess
4. Some dev merges translation branch to trunk => Fix committed
5. A new widelands binary package is released => Fix released

But this is really a bit overhead for only in launchpad missing translatable strings.
Is there a way to automating the updating pots/merging branch to trunk steps at least once a week?
Then the work of ppl translating on launchpad would be visible much earlier in the dev builds...

[Nasenbaer (nasenbaer)]

I partly agree with you Tino. (In case we need a bug tracker item for keeping track about "untranslateable strings" - which I am not yet convinced of), point 1 and 2 seem like a good idea.

However points 3 to 5 do not make sense for me:

1st) this bug report is about "is something translateable" - and I think that's the only thing we should keep track of, because:
2nd) if we take care about if something is translated, we would need a bug tracker item for every possible language Widelands could be translated to - during the time of development (so to say 365days a year ;) ) almost all of those bug reports would be "In Progress" or even just "Confirmed". However to see whether a translation is complete, you can just take a look at the list of translations of Widelands on launchpad.

So my point of view is:

* If new strings are created that are either not translateable at all or that need a catalog update that is not done for some days, a bug report should be created so the issue is kept in mind and hopefully handled soon.
* As soon as the strings are translateable the tracker item should be set to fix released, as again all strings are translateable again (keep point 2nd from above in mind).

[Hans Joachim Desserud (hjd)]

(First of all, I could have set it to Released initially. However, I wanted to include it along all the other bugs which have been fixed in the release cycle for build 18 and it would look odd if some bugs were already considered released before the release itself was out. I guess it didn't need to be strictly tied to build18 as such, but I think it is nice to have a complete list of all the progress and work we have done in a cycle.)

I get the impression we are talking about two separate situations; strings which are not translatable at all, and strings which haven't been added to the translation templates. (This bug belongs in the latter category)

I believe the former should be dealt with as a normal bug, set as fix committed once the string is translatable/added to the templates, and set to fix released when the current development milestone is released.

Furthermore, I think we can avoid the latter type of problems completly by changing the process. I suggest that any patch or new feature which either alters or adds strings should update the translation templates as a final step before it is merged. (Preferably once code review is done, to keep the template related changes out and allow reviewers to focus on the code.) If someone forgots to do this step, it would however be relevant to file a bug. We might then choose to set such bugs to Fix released once it exists in the translation templates. (I would still like it to be tied to the upcoming release milestone, but that's more of a personal preference)

Regarding Tino's suggestion, I don't think it is feasible to keep track of _whether_ something has been translated or not. We currently support 40-50 languages which are more or less actively translated, and realistically we would end up with bug reports which can never be closed. It is of course important to know if something _can_ be translated though.

I do agree we should look into some automated system for merging in new translations more frequently. Currently they happen at random points in time, and it can sometimes go months between. Making the translations availble earlier would allow testers and translators to see them in the game sooner when they are updated, and could spot typos and inconsistency errors earlier. With more rapid releases of translations, we can get feedback sooner. This is possibly a different topic which should be discussed separately though.

[SirVer (sirver)]

I do not really care that much if this is now fix committed or fix released. so I'll just leave it as is now :)

I am not in favor of an automatic solution because we had some cases where english strings where checked in, but we wanted still some proofreading to be done. It would have been bad if they were already translatable than because they would change again.

Also, Widelands development happens irregularly and sometimes lies dormant for months - it makes little sense to have regular translation merges then, imho.

[SirVer (sirver)]

Released in build-18 rc1.