How about somthing like 'NA1001' for errors and warnings.
!--Build Error Strings --
data name=NA1001
valueCould not find a '{0}' file in '{1}'/value
commentSome descriptive comment/comment
/data
What about this? Could be a valid alternative?
Error messages:
data
Hmm - well I'd like the keep the number in there - for
errors/warnings
at least. It will make finding the use of a given error
message easier
later on.
Okay, but tell me which one of the following formats:
data name=NA1001
valueCould not find a '{0}' file in '{1}'/value
Greco Giuseppe wrote:
Hmm - well I'd like the keep the number in there - for
errors/warnings
at least. It will make finding the use of a given error
message easier
later on.
Okay, but tell me which one of the following formats:
data name=NA1001
valueCould not find a '{0}' file in
Greco Giuseppe wrote:
csc ...
...
resources
include name=*.resx/
/resources
/csc
will work just fine.
Just a question: does the resource element automatically
embed the defalut resources into the assembly, or is the
arg element still necessary?
If the name of the .resx
Title: RE: [nant-dev] L16N
Acronyms are horrible class names and are frowned upon by every modern coding standard. When acronyms must be used, they should be used with other nouns that describe what the class is. A utilities class is a utilities class is a utilities class, so ResourceUtils
Ian,
attached to this email you'll find a tar.gz containing the
RESX skeletons. Could you please integrate them into the
project and import them into CVS?
The next steps would be:
1. Decide a standard for string IDs
2. Decide who does what
3. Fill the RESX skeletons
4. Replace hardcoded
Hi Ian,
looks like the xmldoc attribute you mention in a later email
is the way
to get around this. We would invoke ndoc once for each
translated language.
Exactly...
although we should be able to knock up a script to generate
stubs based
on the original english doc.
Of course...
Greco Giuseppe wrote:
Mono source code does not contain documentation comments; XML stubs
are generated via reflection with assembler.exe/updater.exe. Miguel
told me that they want to keep user documentation separated from
source code, meaning the /doc feature of the C# compiler is useless...
Ian,
looks ok - but why not get AssemblyName dynamically using :
Assembly.GetCallingAssembly() ?
then you only need to define the RM class once in NAnt.Core.
It depends if you plan to create separate resource files for the
different NAnt assemblies. Furthermore, it depends also if you
Ian,
looks ok - but why not get AssemblyName dynamically using :
Assembly.GetCallingAssembly() ?
then you only need to define the RM class once in NAnt.Core.
You're right... attached to this email you'll find a better
version of RM.cs (RM stands for [R]esource[M]anager).
Let me know if it
Greco Giuseppe wrote:
Ian,
looks ok - but why not get AssemblyName dynamically using :
Assembly.GetCallingAssembly() ?
then you only need to define the RM class once in NAnt.Core.
You're right... attached to this email you'll find a better
version of RM.cs (RM stands for
Ian,
You're right... attached to this email you'll find a better
version of
RM.cs (RM stands for [R]esource[M]anager).
I figured that one out :). We could probably call it
NAnt.Core.ResourceUtils or somthing like that.
That's up to you... but such a name is a little bit too long
Greco Giuseppe wrote:
I figured that one out :). We could probably call it
NAnt.Core.ResourceUtils or somthing like that.
That's up to you... but such a name is a little bit too long and
uncomfortable to be used often...
you think ? Show me some classes in the core framework that have 2
The first step would be to create the resource files
(NAnt.Core.en-US.resx,
NAnt.DotNet.Task.en-US.resx, etc.),
we can just start with NAnt.Core.resx for the default ( US english )
language.
then replace hardcoded strings with
RM.GetString(Message_Id) - or whatever name you want, and finally
Ian MacLean wrote:
al
target=library
output=${build.dir}/${package.name}/lib/${culture}/${assembly}.resource
s.dll
culture=${culture}
sources basedir=${build.dir}/${package.name}/lib/${culture}
include name=*.resources /
/sources
/al
/foreach
Ian,
I'm at work too... so I cannot start right now...
j3d.
-Original Message-
From: Ian MacLean [mailto:[EMAIL PROTECTED]
Sent: mercoledì, 16 febbraio 2005 08:40
To: Greco Giuseppe
Cc: nant-developers@lists.sourceforge.net
Subject: Re: [nant-dev] L16N
The first step would
Ian MacLean wrote:
Ian MacLean wrote:
al
target=library
output=${build.dir}/${package.name}/lib/${culture}/${assembly}.resource
s.dll
culture=${culture}
sources basedir=${build.dir}/${package.name}/lib/${culture}
include name=*.resources /
/sources
csc ...
...
resources
include name=*.resx/
/resources
/csc
will work just fine.
Just a question: does the resource element automatically
embed the defalut resources into the assembly, or is the
arg element still necessary?
csc ...
arg
Giuseppe Greco wrote:
Do you plan to localize NAnt?
I think it would be a good idea.
If yes, how are you going
to manage translations? Actually, compiled assemblies and
XML files generated by the C# compiler are kept togheter
in the same directory, letting NDoc find them and do its
job.
looks
19 matches
Mail list logo
