This project is read-only.

New features & bugs

Topics: .NET, resgen, resx, ResXFileCodeGenerator, SRGenerator, SRT, StringResourceGenerator, StringResourceTool
Apr 23, 2007 at 1:06 PM
Post them here!

At least 1 new feature maybe very very useful:
- Verification of inserts between culture-specific resource versions. I mean - you could create

SR.strings file with: MSG(string name, string nick) = Hello {0}, you are {1}!
SR.DE.strings with: MSG(string name) = Hello {0}!

SRT2 will generate accessor SR.MSG(string name, strings nick) .
So when you run the program in Germany, you will get FormatException

It will be good to verify this on compile-time, isn't it?
Oct 8, 2007 at 3:52 PM
Edited Oct 8, 2007 at 3:57 PM
Congratulations on reviving SRT, a dear old friend in our toolbag.

WishList #1

When Microsoft put out its SRT under the Enterprise thingy, one difference in their version
is that it respected embedded string escapes -- "\n" in particular. For all I know
they supported all escaped constructs, but \n was the only one I ever cared about.

I encourage you to consider adding specific support to this new version.

Consider this use case:

We take the original developers' SR.Strings files, paste them into excel which then
circulate to our translation facility to fill in (in multiple colums) the translated strings
for the languages we need . This way, the translators see everything in context and
consider the translations among multiple languages as a whole.

Then, when the excel file comes back, we burst it into the individual locale-specific files we need.

It is much easier for the translators to understand our intent if the original english uses
\n's to indicate linebreaks than it is for them to deal with the new line plus = construct.
Also, since our translators understand what we're trying to do w/ linebreaks (space out and
make messages readable) they have the option to reposition the linebreaks in a fashion that
is appropriate for each locale.

Of course it would be even better if we could drive the entire localization from such a
spreadsheet - but I'll save that request for later :-)

Best wishes, and thanks again for reviving this.

Oct 8, 2007 at 3:55 PM
WishList #2

It would be nice if SRT (or a companion add-in) could help identify when a key is present
in the primary locale file (by which I mean the one for which SR.cs is generated) but not
present in one of the subordinate locale files (for which code is not generated)

This is particularly useful during maintenance when the developer adds a new entry to
the primary language -- when there are 3 or more subordinate locales, it can get to be
quite a chore to determine whether that entry was populated in all locales.
Oct 9, 2007 at 9:11 AM
Hi Ralph and thank you for your interest in SRT!

Checking main and subordinate files for consistency is first item in new features list 8))) More, it should also check that same resource has same amount and type of parameters in all the local files. You are absolutely right that at first it is enough just to check that some resoureces have been added - thank you for this reminder!

About '\n' versus newline + '='. Do you really think that '\n' is better? Is the only problem that '\n' is more understandable for people doing translation?
Oct 9, 2007 at 10:45 AM

AlexeyQ wrote:


About '\n' versus newline + '='. Do you really think that '\n' is better?
Is the only problem that '\n' is more understandable for people doing translation?

I take your point, we run into the problem when the strings get
pushed into an excel file for distribution to translators.
And the translators get totally confused by having to do <ctr>Enter
to insert linebreaks in excel.

That said, *I* certainly prefer the \n construct because it is
consistent with the usage in string literals.
(Maybe this could be an option driven by a #! directive)

Consider this snippet from an actual SR file:

ConnectString = Turn on Instrument for at least 20 seconds.
= Attach communication cable.
WaitReady = Wait for system ready light to turn on, test light off.
PressYes =
=Press 'Yes' to start Instrument connection.
=Press 'No' to use viewer only.

When this kind of stuff gets put in a file with ~hundreds~ of strings
(not untypical for some of our applications)