[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Shop UI (was: system logic fault (moving units into a building))



On Sun, Apr 03, 2005 at 08:36:36AM +0000, Jens Granseuer wrote:
> 
> On 02.04.2005 20:01, Torinthiel wrote:
> > Also, is any way of tracking translation
> > synchronization planned? For example, at MPlayer each original file has
> > a $Revision$ tag near start (expanded by CVS automatically) and
> > translations are required to have 'synced with 1.???' near the
> > beginning, all that in comments. This could work for *.tmpl, but not for
> > .usrc and map sources, because these have all translations in one place.
> > And it really makes translating easier - all you have to do is check the
> > tags, and you see if you have to update something. Then cvs diff and you
> > know what to change.
> 
> I'm not sure I understand. Putting in a revision tag is no problem, of
> course. Each tmpl would then have a comment 'needs to be synched with
> en revision xxx' at the top? If so, sure, we can do that.

More like "This has the same messages like en revision xxx, only
translated".

> 
> > And are the comments for translations intentionally omited? Also could
> > save some work.
> 
> What comments are you talking about?

head {en,pl}.tmpl
==> en.tmpl <==
# english language file for Crimson Fields
language=english
id=en

[messages]
_OK
# MSG_B_CANCEL
_Cancel
# MSG_B_YES
_Yes

==> pl.tmpl <==
# polish language file for Crimson Fields
language=polski
id=pl

[messages]
_OK
#
_Anuluj
#
_Tak

I mean the descriptions after #, indicating what the following message
should mean.

> > Maybe add a green light to them, same way as red is added when transport
> > is full? And I'd appreciate if unit selection would be before movement
> > and/or cancel button.
> 
> I just _knew_ someone was going to say that ;-).
> 
> I thought about it long and hard, couldn't decide, and chose the way
> that was esier to implement. There are reasons for doing it before and
> after the move. Logically, the loading process should be before the move.
> However, after you have selected the transport it's still possible to
> abort movement, or you may realize you can't actually move the transport
> where you wanted to go and you lose the loading changes again.
> 
> What do you need the cancel button for?

So that I can change my mind even after selecting movement, but before
selecting units. I.e. a way to escape from loading window without making
decisions. But I can do almost that by undoing move, so I don't insist.
Torinthiel

-- 
 Waclaw "Torinthiel" Schiller       GG#: 542916, 3073512
   torinthiel(at)megapolis(dot)pl
   gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999  D714 7CEB CDDC 0906 A2CE
 "No classmates may be used during this examination"

Attachment: pgpGzvNvoaatm.pgp
Description: PGP signature