Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2003:
[Freeciv-Dev] Re: (PR#2690) [PATCH] Show unit location in its descriptio
Home

[Freeciv-Dev] Re: (PR#2690) [PATCH] Show unit location in its descriptio

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: stepan@xxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2690) [PATCH] Show unit location in its description
From: "Jason Short via RT" <rt@xxxxxxxxxxxxxx>
Date: Sat, 4 Jan 2003 03:41:50 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sat, 2003-01-04 at 06:01, Stepan Roh wrote:
> [patch attached]
> 
> On Fri, 3 Jan 2003, Jason Short via RT wrote:
> 
> > > - moved unit_description() to client/gui-*/citydlg.c (if used by that gui
> > > = gtk, gtk-2.0, xaw, sdl, win32) and changed it to use new
> > > get_nearest_city*() methods
> >
> > Don't put identical copies of the function into each GUI.  Just put one
> > copy into climisc; it's okay if not all GUIs use it.
> >
> > For now I don't suggest changing the users of unit_description.  Later
> > some GUIs may want to do their own formatting, and some may wish to add
> > this information to the mapview panel information for the active unit.
> > But these are separate issues.
> 
> Citation:
> 
> "And perhaps this function is overkill to begin with - it should be left
> up to the GUI code to generate the string (or do whatever layout it wants
> with the data), and all the client-common code should do is provide a
> helper function to find the nearest city."

Well, I meant that a GUI may want to provide a more sophisticated
layout, using widgets instead of just a single string.  But I see now
that it's easy enough for a GUI to do that and still have the function
available in climisc.

> So I provided only get_nearest_city*() functions and distributed
> unit_description() in other GUIs. Moved to climisc.[hc] now.

OK.

> > > - added "from " in front of home city text
> >
> > Seems good to me.  Other opinions?
> >
> > > - text visible before nearest city name is now better translatable (I
> > > hope)
> >
> > I don't see any problems with this, but I'd like to get a translator's
> > opinion.  Remember that some languages may follow entirely different
> > grammar rules.
> 
> I know, I'm Czech. That's why there is _("in %s") (and similar) so others
> may translate whole sentence in some neutral way (necause city name must
> be intact).

In general, I agree that it's okay to translate each line separately,
and this makes things (possibly) easier for translators.

The one problem is the first line of the unit description - it is
hardcoded that the "(veteran)" tag must follow the name of the unit.  I
think this could fail under some languages (perhaps right-to-left ones
or those with different grammar rules about such things).

So, I have one last request: build that line's string into another
independent buffer first.  Use _("%s (veteran)") or "%s" as the format
string.  (See below.)

> +  my_snprintf(buffer, sizeof(buffer), "%s%s\n%s\n%s\n%s", 
> +       unit_type(punit)->name, 
> +       punit->veteran ? _(" (veteran)") : "",
> +       unit_activity_text(punit), 
> +       buffer3,
> +       get_nearest_city_text(pcity_near, pcity_near_dist, buffer2, 
> sizeof(buffer2)));
> +
> +  return buffer;
> +}

The first "%s%s" here is the problem.

jason




[Prev in Thread] Current Thread [Next in Thread]