On 6 April 2014 23:26, Marko Lindqvist <cazf...@gmail.com> wrote:
> On 6 April 2014 17:43, Jacob Nevins
> <0jacobnk.fc...@chiark.greenend.org.uk> wrote:
>> Months ago (on 3 Jan), Marko Lindqvist wrote:
>>>>> patch #4190: Split translations to multiple po-files
>>>>> If we are going to add information about what translation domain
>>>>> translations about the nation should be fetched to the rulesets, it
>>>>> must be done before datafile format freeze.
>>>>  This has been implemented to the extend I dreamed about, but the
>>>> ticket has been given to jtn to further evaluate what more is needed.
>>>  ?
>> I don't now expect to implement anything like the full madness of
>> <http://gna.org/patch/download.php?file_id=19163>, but there's still a
>> minimal level of work required in defining a suitable workflow for
>> importing translations, updating freeciv.pot, updating po-files, etc in
>> a world with multiple translation domains.
>> (This is quite high-priority, because it's indirectly retarding
>> translator work on S2_5 and later.)

 To be honest I see only two problems regarding 2.5 implementation.

 Of those, the only technical one, is that some titles might appear as
strings in both domains, requiring translation twice.
 However, number of those strings is very low in the big picture, and
that mainly affects only new translations in 2.5 - Migration of
existing translations from S2_4 places the translation to both

 The other problem is lack of documentation about migrating
translations from S2_4 to S2_5, and about translating S2_5. But given
that currently almost no translator commits translations themselves,
this is not a big issue, and in any case would not need code changes,
but just instructions sent to i18n list and probably some wiki updates
(about translation work in S2_5 and later).

>>>>> Qt-client
>>>>> Qt-client is coming along so well that it would be a shame not to get it
>>>>> to "supported client" status in 2.5. Mir3x probably keeps on working on
>>>>> Qt4 based version.
>>>  Qt5 now.
>> I haven't been keeping on top of the Qt client. Is there a description
>> of the major missing features at the moment? Perhaps we need a
>> metaticket?
>  We have metaticket patch #4417, but it doesn't have much content - I
> have had only a couple short sessions with Qt-client so not explored
> what it absolutely still needs.

 It will most likely keep its "experimental" status in 2.5.

>>>>  New Qt-client related item is that I'd want freeciv-mp-qt to be in
>>>> good enough shape to be used in those installations that use
>>>> Qt-client, so one does not need to mix gtk-based freeciv-mp-gtk[23] to
>>>> Qt system.
>>>> I'm working on this.
>>> Mostly done
>> Done?
>  I'm not completely satisfied with the quality.

 Still not completely satisfactory, but not needed if Qt-client does
not make it.

>>>>> patch #3448: "Nation sets": allow set of nations that will ever appear
>>>>> in-game to be chosen
>>>>> Affects both network protocol and ruleset format, I think.
>>>>  There has been some progress.
>>>  If I have understood correctly all that is missing is support from
>>> some of the clients. That shouldn't stop us from going toward beta (no
>>> network protocol issues, I assume)
>> That's about right. With the Gtk clients, I consider the feature
>> complete.
>> However, I'm keen that every supported client should have a UI for this
>> feature, even if a minimal one. Otherwise, all the nations maintainers'
>> hard work on the "extended" nation set becomes completely invisible to
>> casual users of that client, which was something I explicitly wanted to
>> avoid when creating two tiers of nations.
>> Help in this area would be appreciated. In particular, I've not done any
>> Qt hacking, so if someone else could add support to the Qt client, that
>> would be great.
>> <http://gna.org/patch/?4350> "Qt client support for nation sets"
>> The SDL client should also have support. I'd be content with minimal
>> support to start with (add a drop-down, but if you change it the nations
>> dialog pops down -- this would save some fiddly widget-wrangling).
>> <http://gna.org/patch/?4351> "SDL client support for nation sets"

 Again, if Qt-client is not going to make it as a whole, missing this
one particular feature is not an issue.

>  I have this in my personal TODO notes in the roadmap of sdl2-client
> development (I expect to learn more of the sdl(2)-client widget code
> by doing other tasks before trying to tackle this)

 I think I can get to actual implementation soon. I already committed
one patch improving things a bit

>>>>> gtk3-client as default
>>>>> Gtk3-client is default client in 2.5. Its remaining issues should be
>>>>> resolved that it would be worthy of that status.
>>>>  There's windows version available now, but it has performance issues.
>>>  It would be nice to get it tested in betas, but not going to put
>>> beta1 to who-knows-how-long wait for this. Blocking final 2.5.0,
>>> though.
>> <http://gna.org/task/?7760> lists possible blockers to Gtk3 as default
>> client. Many are still open.
>> Not on the list is improvement of the Gtk3 custom theme, but that's
>> actually what's been stopping me from using the Gtk3 client more myself,
>> or recommending it to anyone else.
>> Right now I think it's much uglier than the Gtk2 theme, although that's
>> subjective. It certainly takes up much more screen space at the moment.
>  Try using Debian Testing. Here only some minor parts of gtk2-client
> theme work, but gtk3-client one seems about complete. It used to be
> the other way around until some gtk updates.

 I'll be suggesting (opening ticket) reverting to gtk2-client as
default client in 2.5. It's a bit of a lose-lose situation, but I'll
include full reasoning to the ticket. Obviously such an change needs
to go in to beta1 already, or not at all.

>>>>> Missing art: bug #20536, bug #20032, bug #20031, bug #20029, bug #20030
>> Some fixed; bug #20536, bug #20032, bug #20029, part of bug #20030
>> remain.
>> That would be about now. I think we're not ready for beta1 yet. I'd like
>> to have a better grasp on what features are in it and their current
>> state first.
>  Yes, that might reveal some critical problems.
>> We also need to scrub the bugs tagged as "2.5.0". I'm sure I raised some
>> fairly major ones in that category which I didn't immediately
>> investigate, for the sake of not getting distracted from whatever I was
>> doing at the time; I don't know which have since been fixed. There could
>> be some in there severe enough to block beta1.

 - ML

Freeciv-dev mailing list

Reply via email to