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:
Could not find a '{0}' file in '{1}'
Some descriptive
> 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:
Could not find a '{0}' file in '{1}'
Some descriptive comment
Greco Giuseppe wrote:
How about somthing like 'NA1001' for errors and warnings.
Could not find a '{0}' file in '{1}'
Some descriptive comment
What about this? Could be a valid alternative?
Error messages:
Could not find a '{0}' file in '{1}'
Some descriptive comment
o
> How about somthing like 'NA1001' for errors and warnings.
>
>
>
> Could not find a '{0}' file in '{1}'
> Some descriptive comment
>
What about this? Could be a valid alternative?
Error messages:
Could not find a '{0}' file in '{1}'
Some descriptive comment
Giuseppe Greco wrote:
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
How about somthing like 'NA1001' for errors and warnings.
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 strin
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
Greco Giuseppe wrote:
...
will work just fine.
Just a question: does the element automatically
embed the defalut resources into the assembly, or is the
element still necessary?
If the name of the .resx file contains a culture part it will package it
up with any
>
>
> ...
>
>
>
>
>
> will work just fine.
>
Just a question: does the element automatically
embed the defalut resources into the assembly, or is the
element still necessary?
j3d.
-- DISCLAIMER ---
Ian MacLean wrote:
Ian MacLean wrote:
output="${build.dir}/${package.name}/lib/${culture}/${assembly}.resource
s.dll"
culture="${culture}">
...
value="-res:${build.dir}/${package.name}/lib/${default.resources}" />
we can use
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] L16
Ian MacLean wrote:
output="${build.dir}/${package.name}/lib/${culture}/${assembly}.resource
s.dll"
culture="${culture}">
...
value="-res:${build.dir}/${package.name}/lib/${default.resources}" />
we can use the child element for
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 a
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
l
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 b
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 [R]esource[M]anage
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
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 yo
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...
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 co
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
Hi all,
Do you plan to localize NAnt? 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.
In order to be able to translate, let's say, the SDK
doc
22 matches
Mail list logo
