> So, I'm pleased to propose Jorg Heymans, as a committer.
+1
Helma
Sorry Bruno, completely forgot to thank you for all the work.
Bij deze: dank je wel!
Bye, Helma
> -Original Message-
> From: Bruno Dumon [mailto:[EMAIL PROTECTED]
> Sent: Friday, 17 June 2005 17:46
> To: dev@cocoon.apache.org
> Subject: Re: [docs] old docs import done
>
>
> On Fri, 2
Guys,
When the navigation is a matter of creating a query and/or a hand-picked
outline, I really don't think it is THAT important to decide now. When
writing the tutorial I found it practical to keep the various
steps/documents together so I could better focus on what to write and
what was done.
> Yes, I'm thinking of attending the Cocoon GetTogether 2005 in
> Amsterdam, preferably on
>
>[ ] 3/4/5 October (Mon->Wed)
>[X] 5/6/7 October (Wed->Fri)
Bye, Helma
> > I would have thought the husband and two boys were the fulltime job!
>
> Obviously, Helma has at least two full time jobs. It can be argued
> that she has 4 full time jobs. From personal experience having a
> spouse is a full time job and most certainly raising a child is a
> full time j
> On Mon, 2005-06-13 at 18:21 +0200, Bruno Dumon wrote:
>
> > What still needs to be done & issues:
>
> > * Daisy doesn't have a -like tag, we need to decide
> what to do
> > with this. Daisy doesn't have this since the Mozilla/IE editor APIs
> > don't support the creation of this type of tag
Hi Bertrand,
> P.S. Helma, it seems like your mailer is breaking threads sometimes,
> but not always. For example, [2] starts a new thread although it is
> obviously a reply to [3]. If it's easy to fix it might be
> good for our
> archives.
>
> [2]
> http://marc.theaimsgroup.com/?l=xml-cocoo
> > ?
>
> nope, code is an inline tag.
Ok, I'll settle for for now.
> Anyway, I'm thinking that for this and the other issue
> (anchors), for the moment we could simply make sure they are
> not lost during the import, and then see afterwards to do
> something about it.
Ok.
As long as it l
Based on some comments I would like to revise the proposal. Let's focus
first on what info goes where and what the general direction will be.
As things progress, we can focus on explicit processes and, given the
current discussion, the roles/rights.
- the current Daisy site at the zones [1] will
> yes, the usual javadocs, the page generated out of
> trunk/lib/jars.xml and the
> pages generated out of the javadocs of sitemap components.
To me this is API docs and serve a special purpose.
_I_ would be perfectly happy if they were in an accessible place, with
links to it from the "ordin
Reinhard,
> Maybe it has already been discussed and then I'm more than
> happy with a link but
> if not, can you explain the process of how our documentation
> gets published
> (http://cocoon.apache.org)? IIUC,
> cocoon.zones.apache.org/daisy/ is our staging
> area and not the official docum
> Unpublished versions are only shown to people with write access to
> these documents.
True for the SimpleDocument, but not for the navigation tree. I cannot
quickly see changes in the navigation tree unless I publish the latest
version. Or am I doing something wrong?
Bye, Helma
Guys,
I'm aware that I'm not officially a committer (yet), however, I think it
will be a good idea to get explicit consensus on where to locate the
docs and about a rough outline of the future actions.
This is the proposal:
- the current Daisy site at the zones [1] will be the "incubator" for
th
> Could you please publish your proposal today so that I (and
> hopefully Sylvain)
> can review it this evening? IIRC proposals have to be handed
> in by tommorrow.
And don't forget to include (time for) documentation.
Bye, Helma
Please add documentation on the working of this. The exposure will be
better if there is documentation on how it works. It doesn't have to be
pixel perfect, but it should get new users up and running.
Bye, Helma
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Maks
> Another question: how do include anchors within pages? Should I do it
> manually with the HTML view?
No idea, do check it as I'm not sure it'll pass the HTMLCleaner config.
Bye, Helma
> It would be the best if you provided your guideline as a
> template page
> YourPageShouldLookLikeThis.
Good idea.
> OT: Suppose I'd like to review some documents that have not been
> published yet. Is there a special query for that?
Yes, I don't have it from the top of my head, but if you
> It would be even better if you defined classes for the
> different style
> elements you want and disable the ability to arbitrarily use and
> for example.
This is already taken care of in Daisy by the htmlArea plugin and
Daisy's HTMLCleaner
> The htmlArea plugin can be customised so that t
To all document editors,
Seeing Mark's work and my own I decided that we best set some basic
rules for writing the documentation and using particular styling. This
improves a consistent look and prevents tedious cleanup at a later
stage.
This is what I propose (and I know _I_ haven't been consist
> One more thing: I just discovered that when I retire a document, the
> document disappears immediately! Is that right?! I would've
> expected a
> publisher to need to approve my retiring of a document first.
I'm not familiar with the inner working of Daisy. Your assumption sounds
reasonable.
> On http://cocoon.apache.org/mirror.cgi the link to the explanation as
> to why there are no binary distributions points to the old
> wiki.cocoondev.org address (and does not redirect).
Hmm, since this is only a small amount of text I would simply include it
in the page, rather than referring t
> Really, you want it so that editors and publishers can see it, but
> guests can't.
Eh, yes, but since publishers 'automagically' get the editors role as
well, I mentioned the editors only.
> Maybe a switch between published and latest would be good.
This exists for a SimpleDocument (but only
Hi Mark,
Thanks for putting in all the work. I have reviewed the documents,
straightened out some layout glitches and put them live. So you should
now be able to see your work.
> I created a CategoryInDaisy page in the Wiki, so that it is easy to
> record a wiki page as having been transferred.
> Yes, I think we are writing more than a reference manual
> here. Perhaps,
> at the appropriate places we could also talk about unit testing and
> other best practices.
To me it ranges from "executive summary" to user's guide and tutorials
to developer's guide and reference manual and everythi
> That was exactly what I proposed. Our target should be a single
> documentation source deprecating main docs and wiki. If we
> add what is
> the easiest now and leave main documentation aside the whole
> effort will be incoherent.
True, but let's do one step at a time. The wiki is easier to
> >>To aid document reorganisation I think we should encourage a fairly
> >>fine-grained modularity, i.e. single topic pages.
> Wouldn't it be a good start to do a "smart import" of current
> xdocs into
> new documentation structure?
No offense, but "smart import" still means going over each
> OK, the dev list sounds just fine! What do you think about the
> refactoring I'm suggesting? I can do it over the next few
> hours if you
> are agreeable. You are editor-in-chief, so I don't want to start
> without your approval!
:-)
> Getting started with Cocoon
> + Installing the prerequi
Hi Mark,
let's take it slow and use the dev list for discussions. Marking the
subjects with [Docs] (as you've already done) gives the others the
option to join or ignore as they see fit.
If the volume increases the decision to use another mailing list can
always be taken.
> To aid document reor
Problem solved. It works now.
> Any kind of email delay can be expected, as Hermes' inbound SMTP
> services are really flaky, and Daisy only processes its stalled mail
> queue every four hours. So if sending mail doesn't succeed the first
> time, it can take a while before a new mail is being s
> http://cocoon.zones.apache.org/daisy/passwordReminder ;-)
Done that but no email has arrived for more than 10 minutes now.
Bye, Helma
> On this basis, I'd like to propose Helma Van Der Linden as a Cocoon
> committer, and thus our first 'publisher'. She has been participating
> regularly in our community, and has shown a quiet but steady
> interest in
> helping with our documentation, as well as an increasingly clear
> unders
> Daughter woke up early: done. Helma, can you cross-check?
Done. All looks fine. Updated the navigation tree on cocoondev.org and
the first page to reflect the new site.
Now all I need is my editor rights back.
Bye, Helma
Hi Mark,
sorry for being late in replying. Usually weekends are more hectic than
weekdays here.
I cannot grant you editor privileges as Steven is the administrator for
the site. I've asked Steven to "fix" this. In the mean time, just add
comments to any page and I'll be happy to incorporate the
Hi Marc,
I do like the introduction.
> A less time consuming alternative for me would be to Sew it all
> together at Planet Cocoon, as it is already set up with
> infrastructure
> for anyone wishing to join in, tools for workflow, categorisation,
> document hierarchy management etc. If I were
> Linden H van der (MI) wrote:
> >
> > An effort to substancially reduce the number of open issues in
> > bugzilla?
> >
>
> IMO this would be more something for a FirstFriday if these
> are still happening.
Sounds good to me too. Why was the idea dropped
> Do we have something else on our wishlists (some fancy cforms
> features, etc.)?
An effort to substancially reduce the number of open issues in bugzilla?
Bye, Helma
> Le 27 mai 05, à 14:47, Steven Noels a écrit :
> > ...People interested in co-administering Daisy (users, creation of
> > variants, ACL rules, sites): please stand up...
My coworker and local Daisy expert, Patrick Ahles, agrees with helping out in
user-administration provided it requires a limit
> > 1- Current released version
> > 2- Daily SVN 2.1.x
> > 3- Daily SVN 2.2.x..
>
> Good idea, but I'm not sure if we want to have three versions there,
> maybe we should start with the release and go from there?
YES! YES! YES!
I mean: good idea to start with the current released version and go
nt to discourage the effort to create a or deploy a Cocoon
> based CMS. I think its important that it gets done. My point is that
> no mater how easy and automated the process becomes, good
> documentation requires a great deal of human collaborative effort.
>
> On May 25, 2005
> A more general question: what sort of demand do you think
> there is for
> translations of the documentation? Any particular languages?
Being Dutch, and therefore used to use other people's language rather
than my own to get in contact with someone, I'm probably not
representative for the enti
> This will mean that people will be able to do "forrest run"
> and edit the
> content in SVn immediately. As the Daisy plugin matures the
> same will be
> true for content in a Daisy repository. Similarly, if PlanetCocoon
> succeeds we can integrate their content and editing in the same way.
> Well, if you can delete documents from the repository, we can
> move stuff
> across, then delete it when it has been repurposed.
Yep, Daisy can delete documents.
> Well, in my view we shouldn't have an ultimate distinction. They are
> both a part of the same overall documentation.
True, but
> even a simple text editor. The one thing I have learned over the
> years is that using the correct tool for the job makes the job
True.
> Third, Cocoon's documentation is not as bad as people think. I was
> able to put together a fairly complex e-commerce site that included
> custom gen
> > - pick a tool, any tool that meets the criteria I mentioned
> above and
> > start a new set of documentation there. I suggest Daisy.
>
> What you should be concerned about is managing new and existing
> content. This includes some process for accepting vetting, editing/
> correcting and p
> > Daisy already IS set up: www.cocoondev.org/handbook
> >
> > I now use it for the tutorial only, but I really don't mind if it
> > becomes the (temporary?) home of the entire new documentation.
>
> How does Daisy handle xdocs type documents? Is a conversion
> to daisy's format easy?
My cowo
> I have a little time on my hands to actually implement some
> of the things mentioned. My only question is what are others
> possibly doing in parallel setting up some other system. I'd
> rather not duplicate efforts when it turns out someone has
> set up Daisy somewhere by the end of this w
> I think that they are many people around here that can do the
> dirty job to create well formed files (xml, xhtml, etc) but
> few that can write documentation.
Well, I think you might be wrong there in the numbers. I've seen a post,
at least once, where someone writes something like "I'd like
Guys,
with all due respect for the various efforts to improve the
documentation, there is only one way to improvement and that is
screening all the available documentation on validity and clarity and
rewrite/enhance it when it's lacking or write the missing pieces. This
screening process is someth
> There is, but it's pure HTML. It has nothing to do with
> CForms. Unknown
> attributes on fi:styling are just copied to the output, e.g.
> @class and also @readonly.
>
This is still true. I had a look at the stylesheets when this topic was
on.
Bye, Helma
> I disagree. Cocoon has been very open in giving committership in the
> past and will continue to be. But the fact is that committers know
True. With "small group" I only mean that the number of committers is
very small, compared to the total number of users on the lists. This is
just a fact, w
> I'm interested in hearing why you think that committership is
> *the* incentive for people to contribute?
Same here. I may not be a representative of the average user population,
but I don't WANT committership until I'm fully convinced that I can
submit something without breaking somebody else's
n documentation (was: RE: Community health)
>
>
> Linden H van der (MI) wrote:
> > As explained in a private mail to Sebastien, I've taken up the
> > http://www.cocoondev.org/handbook site that Steven
> graciously set up for me. I intend to work on the "mid-level
> >As explained in a private mail to Sebastien, I've taken up the
> >http://www.cocoondev.org/handbook site that Steven
> graciously set up for me. I intend to work on the "mid-level"
> tutorial that was the initial goal for the Cocoon In Action project.
> >Doing it in Daisy is much easier for m
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven graciously set up for me. I
intend to work on the "mid-level" tutorial that was the initial goal for the
Cocoon In Action project.
Doing it in Daisy is much easier for me, since it
> On the other hand, a full author listing means more work
> because of one
> more file to update when we commit a contribution (and the
> need to avoid
> duplicates).
Is it possible to have a script running on the SVN server that extracts
the username of each contributor and appends it to a f
Related projects:
- CoWarp? http://osoco.sourceforge.net/cowarp/
Cocoon-based project:
- Daisy (http://www.cocoondev.org/main/117/42.html)
Bye, Helma
> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]
> Sent: Friday, 29 April 2005 12:42
> To: dev@cocoon.apache.org
> Subj
Hi,
I try to follow all threads on new Cocoon docs and I think I read
somewhere that you've put the docs live. But I can't find the reference
nor the URL where they should be.
Can you give me the URL?
Bye, Helma
Hi,
I stumbled onto a problem I've noticed before (Cocoon 2.1.5 I think). I
was under the impression it was solved,
but apparently not.
Situation is this:
- SVN checkout of BRANCHES
- Build a form definition with
var success=true;
return success;
> "my SoC is bigger than yours".
> Ok, people, enough bikeshedding.
>
> Let's get back to work.
And all this because of an introduction to a Cocoon tutorial. Now I
remember why I didn't want to write this part in the first place.
Let's SHOW Cocoon's features and let everyone judge for themselv
> What about an assert validation on "value"?
Sounds like a good idea, so I tried it. Thanks.
It doesn't work yet the way I want it to, so I've probably messed up the
test, I'll look into that on Monday.
However, writing the test showed that this is a very cumbersome way to
handle it. As I've alr
> What about a custom validator?
Sounds like a good idea, but I have no clue how to do this in a generic
way. The next XML fragment could have the value defined as a set of
elements, e.g.:
vs.
John
L.
Doe
How to handle both (the telecomaddress with it's value as an attribute
and the n
Guys,
can someone with in-depth knowledge of the CForms widgets help me out
here? I want to build a form that can be used to enter an HL7v3
TelecomAddress[1]. The final XML result looks like this:
or
tel:+3112345678"/>
I've managed to build the appropriate widget structure for it, but I
have
dev@cocoon.apache.org
> Subject: Re: SVN HEAD: logkit.xconf error
>
>
> Linden H van der (MI) wrote:
> > Guys,
> >
> > the most recent version of logkit.xconf in the HEAD results in an
> > exception (something like LogKitTarget [1] not found). I've
> upda
Guys,
the most recent version of logkit.xconf in the HEAD results in an
exception (something like LogKitTarget [1] not found). I've updated my
local version 15 minutes ago, did a clean build and the error was there.
I then reverted to the previous version of logkit.xconf, did a clean
build and the
Hi,
Although Sebastien can answer for himself, I've asked exactly the same
question. Answer: he only has access to PHP-hosting, no Java hosting.
If someone would offer a Cocoon hosting or Daisy hosting for the
project, I personnaly be happy to move the content there.
Bye, Helma
> -Origina
Guys,
I know it's not done to mail to a mailing list with the return receipt
on. I've been notified be a few of you already, for which I thank you.
However, it's default turned "on" here, and I often forget to turn it
off before mailing to a Cocoon list.
I try to remember, but every now and then
To give this some momentum AND because I haven't figured out yet how to
submit something to Sebastien's CMS, I'll post my proposal here:
The idea is: build a simple website using Cocoon and expand it as
time/tutorial and such progresses.
---
You are a web developer wanting to use Cocoon for the
Hi,
just a quick hack/overview of what I have in mind. All this can be
added/modified etc. This is more or less how I did it. Note: I'm not in
favor of making this tutorial a "showcase" of all things possible. That
would make the tutorial either too large and too complex.
Another idea: once finish
Hi,
sorry I've been too busy lately to participate in anything I've promised
over time. It's not that I don't want to do it any more, just time...
well, you know.
Reading this thread, something clicked as I've been working on a simple
website using Cocoon with simple XML files as "backend". So no
-
> From: David Crossley [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 19 March 2005 04:08
> To: dev@cocoon.apache.org
> Subject: Re: [2.1.7 Testing Results - Forms block, samples] - update
>
>
> Antonio Gallardo wrote:
> > Linden H van der (MI) dijo:
> > >
>
Guys,
I've been working on bug fixing the forms samples which results in 1 - 3
line patches of about 40 files. What's the most efficient way of
creating and submitting these patches?
I only have Eclipse to create patches.
Bye,
Helma van der Linden
Medical Informatics
University Maastricht
POBO
Hi,
I fixed several of the problems below, but it results in 1 to 3 line patches of
about 40 files. What's the most efficient way of handling this?
Bye, Helma
-Original Message-
From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
Sent: Fri 3/18/2005 15:51
To: dev@cocoon.apach
> -o0o-
>
> - URL http://localhost:/samples/blocks/forms/v2/example
> Validation rule "value-count" cannot be used with strings, error at
> file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2
> /form1.xml:115:38
I'll see what I can do.
> - URL
> http
sorry, turned out to be a remnant from a previous attempt to develop a
"exist-block-inject" package.
Sorry for the noise.
Bye, Helma
> -Original Message-
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Friday, 18 March, 2005 14:10
> To: dev@cocoo
Guys,
I checked out HEAD from SVN yesterday and now I'm trying to build it. I
did nothing more than "build clean" and "build webapp" and this is the
result:
D:/svn/cocoon/tools/src/check-jars.xsl:155:40: Warning!
File optional/commons-fileupload-1.0.jar appears in the lib/
directory, but is not
> >So, to sum it up: "readonly" as attribute is supported in
> the current
> >version of the styling XSL files, but there will be no
> widget support
> >for this due to security issues. If treatment of the "readonly"
> >attribute should differ from the current situation, it is up to the
> >us
> Reading the HTML spec [1], the difference between disabled
> and readonly are:
> - readonly is only available on and . disabled is
> available on all controls
> - readonly sends back the value to the server, which is of no
> use if the
> widget is not active
> - readonly inputs receive focus
> Ok. He can add whatever attribute to his styling, the stylesheets are
True.
> built for this, but I don't want to see this "readonly" attribute
> handled in the stylesheets, as we have other mechanisms for
> this, namely widget states.
Agree, however, "readonly" is part of the HTML textarea
Sylvain,
I think he means that adding "readonly='readonly'" as attribute to his
own tag is passed through the styling XSL files. IIRC there
is a template that deals with extra attributes in the styling tag.
HTH.
Bye, Helma
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PRO
Title: Message
Sounds
like a good idea. Since I'm working on the styling XSL sheets anyway, should I
include this?
Bye,
Helma
-Original Message-From: depub2
[mailto:[EMAIL PROTECTED] Sent: Tuesday, 15 March 2005
19:58To: CocoonDev; [EMAIL PROTECTED]Subject: RE: Re:
CO
>
> Talking about users too lazy to read the docs :-)
> http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transf
ormer.html#Attributes
Umph, I read this page about a dozen times, even when I was looking for
the answer to this problem, but somehow I either missed it or it didn't
click. :-(
Hi Jeremy,
> you can specify the catalogue name in i18n attributes like this:
>
>
Thanks for replying, I already deducted this from a discussion some
years ago where Bruno suggested this. Talking about hidden
docs/features. ;-)
> However, the forms catalogue has always been the default
> (wh
Just for the record: nested repeaters are supported. I don't have the
samples at hand, but if you look at the list of samples just before the
dream team sample, you'll see 3. One of them demonstrates nested
repeaters.
Bye, Helma
> -Original Message-
> From: Mark Lowe [mailto:[EMAIL PROTE
> Sent: Sunday, 13 March 2005 20:22
> To: dev@cocoon.apache.org
> Subject: RE: CForms Binding - Cross Referenced Data
> (duplicate of post on users)
>
>
> Linden H van der (MI) wrote:
> > Hi,
> >
> > Just a quick response.
> >
> > What you desc
Hi,
Just a quick response.
What you describe here are two entities: rooms and persons. It is much
more common sense to treat them separately, i.e. a list for editing
persons (just a repeater) and a list for editing rooms (simple list?)
and finally, maybe a doubleList for adding persons to a room
I'd love to add my version of the forms block samples to 2.1.7, but it's
not finished yet (mostly cosmetic changes are needed). I could dump it
in bugzilla in its current state and use the rest of the week for "bug
fixes".
I merely copied the forms samples dir so there is duplicated code there.
W
Found this one too somewhere in an old message:
Now all I need are translations ;-)
Bye, Helma
> -Original Message-
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 23:51
> To: dev@cocoon.apache.org
> Subject: RE: CForms sa
it's in the
forms catalogue.
Thanks.
Bye, Helma
> -Original Message-
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 21:56
> To: dev@cocoon.apache.org
> Subject: RE: CForms samples for 2.1.7 - i18n question -
> upd
> -Original Message-----
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 21:02
> To: dev@cocoon.apache.org
> Subject: RE: CForms samples for 2.1.7 - i18n question
>
>
> Bertrand et Sylvain,
>
> Right now, no i18n works. In core
ilto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 20:00
> To: dev@cocoon.apache.org
> Subject: Re: CForms samples for 2.1.7 - i18n question
>
>
> Le 12 mars 05, à 19:01, Linden H van der (MI) a écrit :
>
> > ...I've managed to get the i18n for the flowscrip
Hi,
I've managed to get the i18n for the flowscript samples to work, by
moving around the i18n transformer. However, I haven't succeeded in
properly translating i18n info that is introduced in the
forms-*-styling.xsl files. It seems impossible to add the i18n
transformer a second time.
So, what t
ested
>
>
> On Sat, 12 Mar 2005, Linden H van der (MI) wrote:
> hi helma
>
> do you want a grrek translation too, or it would be difficult
> to handle
> greek language?
>
> regards
>
> stavros
>
>
> > THANKS a lot.
> >
> > I'm put
ot yet complete, but every bit helps.
Thanks.
Bye, Helma
> -Original Message-
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 15:06
> To: dev@cocoon.apache.org
> Subject: Re: Question on CForms - relevant for 2.1.7
>
>
> Le 12
[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 14:45
> To: dev@cocoon.apache.org
> Subject: Re: Question on CForms - relevant for 2.1.7
>
>
> Le 12 mars 05, à 14:30, Linden H van der (MI) a écrit :
> > ...What I'd like to know is: how many differences are there betwee
Guys,
I don't manage to stay current on the ins and outs of CForms, current
state and its future. I'm currently working on removing the tablebased
layout from the forms-*-styling.xsl files. I would very much like it to
be added to 2.1.7, so I'm doing my best to get it done before the code
freeze.
> > I don't see this here, just did svn up and a full build of the
> > BRANCH_2_1_X, and
> > http://localhost:/samples/blocks/forms/form1.flow works
> fine, and
> > the localized versions look ok as well.
>
>
> Works for me also. Helma, you should try a "build clean webapp", as
> "NoSuchM
Guys,
Today I checked out the latest HEAD version and got it to build
successfully (the out-of-the-box settings). However, when I started the
form1.flow sample it gave me a blank page and a stacktrace in the
console about "no such method". Since this one is also used for the
localized versions in
Hi,
since you're updating the FormsMessages file, could you add an entry
Your local name for a Calendar
here
I'm working on the forms-samples-styling.xsl files and in the meantime I
try to fix a little "TODO" to provide a localized "alt" to the calendar
image.
Thanks.
Bye, Helma
> -Orig
In my attempt to fix the locales samples in the Cforms samples block, as
well as adding a localized calendar image alt attribute, I came across
some odd behaviour:
In the pipeline "form1" of the sitemap of these samples, i18n is called
twice, so I assumed this can be done. However, when I do this
To all the guys that provided the translation: thanks!
Bye, Helma
1 - 100 of 104 matches
Mail list logo
