On Wed, 12 Aug 2015 19:24:38 +0200 win...@genial.ms wrote: > I'd say removing them from the base resources should be done. > We could move them into a trivial new mod, which just overwrites the 2 > resource keys and contains the fonts. I'm not sure if thats useful.
The win I would like to see is for us to just not package them any more. > The code I wanted to add for checking if strings are compatible with > the font will take a bit longer. I could easily hack it in on all > call sites, but I don't like that solution, as it would often need > to extract the string from a JLabel, which was just created inside > Utility together with the Message call to translate it. > These Utility methods look trivial, almost tempting to get inlined, > because there is a huge amount of overloads already and I might need > to triple that amount. Sometimes there is no better solution than a lot of overloading. The alternative is imposing a lot of discipline on the call sites. Up to you. > While looking at Utility I felt I had found some inconsistency with > the Message handling. > Sometimes there is a direct call to Messages.message(stringkey) > and other times Messages.message(StringTemplate.key(stringkey)). > They seem equivalent to me, but the first trims the string, the > second does not. Do you know why? Could that trim call be removed? My guess is this is just a historical accident. StringTemplate is still relatively new. All i18n used to go through the first call, and yes, that was often really awkward. There are a lot of places where we really want to pass a StringTemplate, but some callers just have a simple key, so there has to be some way to bridge the gap. As to the trimming... I had not idea it did that. Would you like to try removing it and see what breaks? Quick warning that next week or so is looking extra busy for me, and I have almost cleared the patch queue of stuff that has had sufficient testing, so do not be surprised if I go quiet for a bit. Cheers, Mike Pope
pgpDvOS2Iu_CQ.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
