You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Paul Ercolino <so...@gmail.com> on 2005/04/10 23:06:27 UTC
Helpful Notes about Installation (and Suggestions for Developers)
Dear Lenya users,
Here are some notes to reduce headaches if you follow the current
installation instructions with:
j2sdk1.4.2_06
jakarta-tomcat-5.0.28
cocoon-2.1.6
apache-lenya-1.2.2
Suggestions for the developers are also included.
1. Installing on Windows
The file "build.bat" shipped with the Windows installer is not
readable by Windows. Open the file using WordPad (not Notepad) and
click Save to fix the line-breaks.
- Hopefully the developers will package a repaired file in the next release.
2. Installing on Linux
The batch files are not executable, giving a "bad interpreter:
Permission denied" error. Fix with:
chmod +x *.sh
3. (Linux) Do not start Tomcat using jsvc.
Do not use jsvc. It causes errors concerning various Cocoon files
when using a publication. Boot scripts should call Tomcat's
startup.sh and shutdown.sh.
4. Fix the languages.
Lenya uses the language in the URL for content, but i18n uses the
browser's locale setting. Why display German content with French
buttons? All text should change if a visitor selects a different
language.
The i18n setting is legacy Cocoon code, and should have been changed
when Lenya started using the URL to set language. To fix, change
every xmap from:
<map:parameter name="locale" value="{request:locale}"/>
To:
<map:parameter name="locale" value="{page-envelope:document-language}"/>
Hopefully the developers will fix the next release. They can also add:
<map:match pattern="**/"><map:redirect-to
uri="index_{request:language}.html"/></map:match>
if they add request:language, with a resource-exists check in case the
language is not used in the publication.. Using request:locale is
difficult because some locales include the country: "en_US", and
substring-before() returns empty if no match.
My current site only has 2 languages, so I used:
<map:select type="parameter"><map:parameter
name="parameter-selector-test" value="{request:locale}"/><map:when
test="xx"><map:redirect-to uri="index_xx.html"/>
5. Adding languages
To add language, add a translation file (cmsui_xx.xml) to the global
apache-lenya-1.2.2\build\lenya\webapp\lenya\resources\i18n directory
as well as the publication's {pub}\lenya\resources\i18n, or the local
file will not be used.
Also, catalog.xsp has the loading backwards. If you want the pub's
i18n to be used first, move the global xi:include before code for the
publication.
6. Login fallback.
It is difficult to override the global login. You can override the
page displayed in {pub}\lenya\xslt\ac, but it is difficult to reuse
XSL in both {pub}\lenya\xslt and {pub}\xslt. <xsl:import
href="../../xslt/myCommonXSL.xsl"/> never returns.
Fix the global xmap to use better fallback, or create a new usecase.
(I did the latter so my publication is portable until the developers
fix this. Newbies should do the former.)
Also, merge the {pub}/lenya/xslt into {pub}/xslt. Why do we need
separate places for publication-specific XSL? All the global
overrides can remain in subdirectories so the code is kept separated.
Do the same for "resources" and maybe "content". (The "content"
directories have different uses, but the global "content" mixes
sitetrees and XSPs, so maybe combining them is fine.)
7. (Advanced) JXPath Flow scripts trash HTML.
<fd:selection-list type="flow-jxpath" list-path="dynamicField"
value-path="value" label-path="label">
Values returned cannot contain HTML or XML. Cocoon has a "feature"
that checks if the values are "XML-izable" and converts angle
brackets.
(Why damage data? The first use of Cocoon's JXPath Flow probably
needed XML, put the translation too low in the architecture, and now
we are stuck with it.)
8. Members' Only Section
The press releases mention this feature is easily implemented, but I
could not implement it after much research. The Wiki documentation for
"ClosedUserGroupHowto" is useless.
Members' Only Sections should:
- Disappear from menus if not logged in (although an option to display
the top-level document to force the login would be nice.)
- Not show the documents in Search without appropriate login.
(Was there was functionality using "auth-protect"? Many websites
refer to it, but Lenya does not use the Cocoon code.)
This function should be implemented in 2 places:
Control the menus by adding parameters to the live sitemap.xml, like:
<node id="employeeSection" visibleinnav="role" roleRequired="employee,admin">
True security (forcing a login before allowing access) should be in
the subtree-policy.acml under {pub}/config/ac/policies. The (new?)
"Inheriting Policy Manager" will make this difficult unless a subtree
can override a parent:
<ac:world><ac:role id="none"/></ac:world>
The best solution for integrating with Search is to add a
"roleRequired" element to each "hit" (using a function or XSL?), then
add another XSL filter in the xmap to remove denied entries. Or
should it be filtered in one pass?
- Must avoid patching Lucene.
- Using multiple indexes would quickly become very complicated and
drivespace-intensive when several sections require different
one-of-several roles.
- Adding areas would confuse the publishing code, and could make
sitewide search difficult. "search-live" should return all live pages
allowed to a visitor.
--
The http://lenya.apache.org/community/mailing-lists.html does not give
the email address for the user mailing list. The dev address is tiny
at the bottom.
Will the developers notice this here? Should I send these items to the
dev mail list? Do I need to register with the Bugzilla? None of
these issues were mentioned in Bugzilla.
Helpfully,
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Michael Wechner <mi...@wyona.com>.
Paul Ercolino wrote:
>Will the developers notice this here?
>
yes
>Should I send these items to the
>dev mail list?
>
I think most devs are also subscribed to the user list, but it probably
makes sense next time
> Do I need to register with the Bugzilla?
>
yes, please add your suggestions to Bugzilla
Michi
> None of
>these issues were mentioned in Bugzilla.
>
>Helpfully,
>solprovider
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
>For additional commands, e-mail: user-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by so...@gmail.com.
Paul wrote:
> > Document creation could create every language version. That feature
> > would be a great time-saver for sites with many languages. The alternate
> > language versions can be removed if unneeded.
Andreas wrote:
> That's certainly worth an enhancement bug. What about a checkbox "create all
> language versions" on the create screen?
It should default to "Create all language versions". While Lenya
could maintain completely separate websites for different languages,
that defeats the purpose of of a multi-lingual CMS. If the document
is created in every language, it helps prevent that other-language
maintainer from creating a similar document with a different key.
Paul wrote:
> > I do not understand why i18n should not follow the document language. What am I
> > missing?
Andreas wrote:
> OK, I see your point, but I'm not sure if I agree :)
> What do the others think?
I am new here, but I have tons of experience with this type of
software. Always ask "What will the visitor expect?" If the browser
was set to French, but the visitor chose to read in German, should the
buttons stay in French? Ask your favorite non-techie what they would
expect.
>> Paul wrote long suggestion for improving the access control system.
> Sounds reasonable. Would you mind filing an enhancement bug with this
> specification?
>
> Thanks again,
> -- Andreas
Again, I am new here. While I have used and recommended OSS for
years, I am not familiar with procedures for contributors. I am
currently working on a major revamping of Publication Search. I will
post those instructions here (as a new top-level entry) when it is
finished. I expect to be very busy for at least 2 weeks. Can this
wait until I have some free time to learn about Bugzilla?
I recommended and am using Lenya for a client project, so you'll get
tons of enhancements and suggestions while I am active with it. I am
avoiding modifying the underlying Java (such as that Cocoon "feature".
I just worked around it.) The "Login/New Registration" page is good.
The new "Search" will be good. Could I send the finished Publication
to someone who can modify the "default" template? The only
server-wide change (so far) is the language issue. Of course, if you
accept my suggestions, many of my enhancements will become obsolete.
Please contact me if you know how to implement a Members' Only section
that integrates with Search. A good solution may not be possible
without revamping the Access Control system. Hacking around these
issues is taking days.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Michael Wechner <mi...@wyona.com>.
J. Wolfgang Kaltz wrote:
> solprovider@gmail.com schrieb:
>
>> (...)
>>
>> My issue was the languages should never be different. Andreas
>> mentioned that the Editor GUI uses i18n. I replied there were very
>> few functions where an editor would not understand the language of the
>> content being edited, and suggested an enhancement to remove one
>> issue.
>
>
> IMHO I don't think the CMS GUI language should have anything to do
> with the content language. As a CMS user, I want to have the language
> I am used to, independently of the current content.
agreed
>
>
> So bottom-line, IMHO given the current state of Web browser usage, I
> don't believe in using the browser-language setting as valid information.
What about introducing a language menu item within the Help menu in order to
explain at least as a workaround.
I think in the longrun Lenya needs to offer a "My settings" or something
like that
link.
Michi
>
>
> Wolfgang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> solprovider@gmail.com schrieb:
>
>> (...)
>>
>> My issue was the languages should never be different. Andreas
>> mentioned that the Editor GUI uses i18n. I replied there were very
>> few functions where an editor would not understand the language of the
>> content being edited, and suggested an enhancement to remove one
>> issue.
>
>
> IMHO I don't think the CMS GUI language should have anything to do with
> the content language. As a CMS user, I want to have the language I am
> used to, independently of the current content.
> Example: I am looking at the start page, for which a german and an
> english version exists. I do not want the labels for the CMS menus to
> change, depending on whether I'm currently working on the english, or
> the german content.
> Or am I misunderstanding the issue ?
I share this opinion.
>> I modified Lenya to choose the homepage based on the visitor's
>> browser's language. Standard Lenya uses the default language until
>> the visitor chooses another language.
>
>
> I agree that in theory, using the visitor's browser language would be
> the way to go.
This could be an option, but not the only possible way. What about
statically served sites?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
setting the lenya user for unix tomcat builds
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
solprovider@gmail.com wrote:
> Thank you. I had rerun the Lenya install, and forgot to fix the owner again.
>
> Should the installer be modified to set the owner? Two lines should solve this:
> LENYA_OWNER=lenya
> chown -R $LENYA_OWNER $tomcat.webapps.dir
> Just need to figure out where to put them.
the owner would have to be a build property
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by so...@gmail.com.
On Apr 12, 2005 6:37 AM, Dave Sunerton-Burl <da...@lledr-solutions.co.uk> wrote:
> > Anyone know why Lenya
> > does not work in Tomcat if Tomcat is started by jsvc?
> We're running Lenya in Tomcat using jsvc without problems - check the
> permissions for the user tomcat is running as and make sure you haven't
> copied any files over (manually) which that user wouldn't be able to
> access. If in doubt, just chown the Lenya webapp folders/files to the
> tomcat user.
Thank you. I had rerun the Lenya install, and forgot to fix the owner again.
Should the installer be modified to set the owner? Two lines should solve this:
LENYA_OWNER=lenya
chown -R $LENYA_OWNER $tomcat.webapps.dir
Just need to figure out where to put them.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Dave Sunerton-Burl <da...@lledr-solutions.co.uk>.
>
> That sums my thoughts about the language issue. Anyone know why Lenya
> does not work in Tomcat if Tomcat is started by jsvc?
>
We're running Lenya in Tomcat using jsvc without problems - check the
permissions for the user tomcat is running as and make sure you haven't
copied any files over (manually) which that user wouldn't be able to
access. If in doubt, just chown the Lenya webapp folders/files to the
tomcat user.
--
Dave Sunerton-Burl
Lledr Solutions
Email : dave@lledr-solutions.co.uk
Phone : +44 (0)1690 750446
Web : www.lledr-solutions.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
solprovider@gmail.com schrieb:
> On Apr 12, 2005 5:14 AM, J. Wolfgang Kaltz
> <ka...@interactivesystems.info> wrote:
>
>>IMHO I don't think the CMS GUI language should have anything to do with
>>the content language. As a CMS user, I want to have the language I am
>>used to, independently of the current content.
>>Example: I am looking at the start page, for which a german and an
>>english version exists. I do not want the labels for the CMS menus to
>>change, depending on whether I'm currently working on the english, or
>>the german content.
>>Or am I misunderstanding the issue ?
>
>
> You understand, but there are several issues here:
> 1. Content language is chosen by visitors.
> 2. Site navigation is controlled FOR ALL VISITORS by the browser setting.
> 3. The CMS maintainers want the CMS GUI to remain in the langauge of
> their choice regardless of the language of the content being edited.
> 4. The CMS GUI uses the same code as the Site navigation.
>
> Compromise?
> - All site navigation should follow the visitor-chosen language.
> - The CMS GUI should use the browser language.
> So the modification in the top post should only be applied to the
> publications. At least change the "default" publication since the
> common (only?) method of creating new publications is to copy that
> directory.
>
> Or get the CMS GUI language setting from the Identity file for the
> user. That requires another setting on the User screen.
Yes, in fact Torsten was recently working on that feature, because he
supports CMS editors who are not always at the same location (such as
Internet cafes), and can not control their browser setting, even if they
wanted to.
I know he is quite busy these days but will ask him ASAP to see how far
he got.
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by so...@gmail.com.
Andreas Hartmann <an...@apache.org> wrote:
> Does it? IIUC the CMS GUI uses the Cocoon i18n based on the {request:locale},
> the content uses the {page-envelope:document-language} which is based on
> the URL. Or am I missing something?
> Josias Thoeny wrote:
> > I just tried the default publication of Lenya 1.2.x.
> > The menu on the left side in the authoring view always is displayed in
> > english (e.g. the Features item), no matter if I visit a german or an
> > english page. In other words, the content of a page is translated
> > correctly according to the url (e.g _de), but the navigation (menu and
> > tabs) are not. (The locale has not influence on that)
> > This seems to be a bug, or is there something wrong with my setup?
> I can confirm this, it seems to be a bug. Is this a new issue?
> It's strange that nobody ever noticed it ...
> BTW, it works correctly in the trunk.
> -- Andreas
All the installed sitemaps sent {response:locale} to i18n
transformation, so i18n would always use the browser language. This
affects the CMS GUI and production site navigation.
Production site navigation depends on the developer. If i18n is used,
then the browser setting is used. If page2xhtml.xsl uses code like:
<xsl:when test="$language = 'xx'">
then it depends on how the language variable is set.
[I pass language as a parameter from the sitemap using
page-envelope:document-language. Is that information available to XSL
from some global?]
Oops. Site naviagation also refers to the menu.xsl and
breadcrumb.xsl. Yes, they correctly use the document language.
Above, I was referring to items like the Search button and a Login
link.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: schema imports another schema
Posted by Lee Carroll <le...@aol.com>.
> Quite a few people were mentioning this problem before and I think it
> would make
> sense to fix this somehow. But I am not sure how what would be the best
> solution.
> Of course we could add a pipeline to the Lenya core which would match
> all URLs with the suffix "xsd", but I don't think this is a good idea.
>
> HTH
>
> Michi
>
Of course !
Thanks Lee C
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: schema imports another schema
Posted by Michael Wechner <mi...@wyona.com>.
Lee Carroll wrote:
> I've come up against a problem trying to load a schema which imports
> another schema
>
> The url used for the schema is:
>
> {request:requestURI}?lenya.usecase=display&lenya.step=loadXSD
>
> The match is below with a simple read of the xsd
>
> <map:match pattern="loadXSD" type="step">
> <map:read
> src="{global:basedir}/pubs/{page-envelope:publication-id}/lenya/resources/generalPage/generalPage.xsd"/>
>
> </map:match>
>
> The imported schema is in the same directory and referenced relatively
> like
>
> schemaLocation="fragment.xsd"
>
> The generalPage xsd is found fine but fails to be vaild as the import
> fails ???
one needs to add a pipeline to the publication sitemap in order to "allow"
the loading of the referenced XSD. (it should get clearer from the
logfile, resource not found or something similar)
Quite a few people were mentioning this problem before and I think it
would make
sense to fix this somehow. But I am not sure how what would be the best
solution.
Of course we could add a pipeline to the Lenya core which would match
all URLs with the suffix "xsd", but I don't think this is a good idea.
HTH
Michi
>
> Any Ideas
>
> Lee C
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
schema imports another schema
Posted by Lee Carroll <le...@aol.com>.
I've come up against a problem trying to load a schema which imports another
schema
The url used for the schema is:
{request:requestURI}?lenya.usecase=display&lenya.step=loadXSD
The match is below with a simple read of the xsd
<map:match pattern="loadXSD" type="step">
<map:read
src="{global:basedir}/pubs/{page-envelope:publication-id}/lenya/resources/generalPage/generalPage.xsd"/>
</map:match>
The imported schema is in the same directory and referenced relatively like
schemaLocation="fragment.xsd"
The generalPage xsd is found fine but fails to be vaild as the import fails
???
Any Ideas
Lee C
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Andreas Hartmann <an...@apache.org>.
Josias Thoeny wrote:
> On Tue, 2005-04-12 at 15:25 +0200, Andreas Hartmann wrote:
>
>>Josias Thoeny wrote:
>>
>>[...]
>>
>>
>>>I just tried the default publication of Lenya 1.2.x.
>>>The menu on the left side in the authoring view always is displayed in
>>>english (e.g. the Features item), no matter if I visit a german or an
>>>english page. In other words, the content of a page is translated
>>>correctly according to the url (e.g _de), but the navigation (menu and
>>>tabs) are not. (The locale has not influence on that)
>>>This seems to be a bug, or is there something wrong with my setup?
>>
>>I can confirm this, it seems to be a bug. Is this a new issue?
>>It's strange that nobody ever noticed it ...
>>
>>BTW, it works correctly in the trunk.
>>
>
>
> I tracked down the problem to a missing namespace url in
> SiteTreeGenerator.java, line 158.
>
> Insert "http://www.w3.org/XML/1998/namespace" as namespace uri of the
> xml:lang attribute and it should work again.
Thanks, that fixes it. BTW, the namespace URI is available as
org.xml.sax.helpers.NamespaceSupport.XMLNS
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for
Developers)
Posted by Josias Thoeny <jo...@wyona.com>.
On Tue, 2005-04-12 at 15:25 +0200, Andreas Hartmann wrote:
> Josias Thoeny wrote:
>
> [...]
>
> > I just tried the default publication of Lenya 1.2.x.
> > The menu on the left side in the authoring view always is displayed in
> > english (e.g. the Features item), no matter if I visit a german or an
> > english page. In other words, the content of a page is translated
> > correctly according to the url (e.g _de), but the navigation (menu and
> > tabs) are not. (The locale has not influence on that)
> > This seems to be a bug, or is there something wrong with my setup?
>
> I can confirm this, it seems to be a bug. Is this a new issue?
> It's strange that nobody ever noticed it ...
>
> BTW, it works correctly in the trunk.
>
I tracked down the problem to a missing namespace url in
SiteTreeGenerator.java, line 158.
Insert "http://www.w3.org/XML/1998/namespace" as namespace uri of the
xml:lang attribute and it should work again.
Josias
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Andreas Hartmann <an...@apache.org>.
Josias Thoeny wrote:
[...]
> I just tried the default publication of Lenya 1.2.x.
> The menu on the left side in the authoring view always is displayed in
> english (e.g. the Features item), no matter if I visit a german or an
> english page. In other words, the content of a page is translated
> correctly according to the url (e.g _de), but the navigation (menu and
> tabs) are not. (The locale has not influence on that)
> This seems to be a bug, or is there something wrong with my setup?
I can confirm this, it seems to be a bug. Is this a new issue?
It's strange that nobody ever noticed it ...
BTW, it works correctly in the trunk.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for
Developers)
Posted by Josias Thoeny <jo...@wyona.com>.
On Tue, 2005-04-12 at 14:36 +0200, Andreas Hartmann wrote:
> solprovider@gmail.com wrote:
> > On Apr 12, 2005 5:14 AM, J. Wolfgang Kaltz
> > <ka...@interactivesystems.info> wrote:
> >
> >>IMHO I don't think the CMS GUI language should have anything to do with
> >>the content language. As a CMS user, I want to have the language I am
> >>used to, independently of the current content.
> >>Example: I am looking at the start page, for which a german and an
> >>english version exists. I do not want the labels for the CMS menus to
> >>change, depending on whether I'm currently working on the english, or
> >>the german content.
> >>Or am I misunderstanding the issue ?
> >
> >
> > You understand, but there are several issues here:
> > 1. Content language is chosen by visitors.
> > 2. Site navigation is controlled FOR ALL VISITORS by the browser setting.
>
> Hmmmm, I think I misunderstand something ...
> The site navigation language is based on the document language which
> is determined by the DocumentBuilder based on the URL. For instance
> the DefaultDocumentBuilder chooses the default language if no suffix
> "_*.html" is provided, otherwise the language denoted by the suffix.
>
> > 3. The CMS maintainers want the CMS GUI to remain in the langauge of
> > their choice regardless of the language of the content being edited.
> > 4. The CMS GUI uses the same code as the Site navigation.
>
> Does it? IIUC the CMS GUI uses the Cocoon i18n based on the {request:locale},
> the content uses the {page-envelope:document-language} which is based on
> the URL. Or am I missing something?
>
I just tried the default publication of Lenya 1.2.x.
The menu on the left side in the authoring view always is displayed in
english (e.g. the Features item), no matter if I visit a german or an
english page. In other words, the content of a page is translated
correctly according to the url (e.g _de), but the navigation (menu and
tabs) are not. (The locale has not influence on that)
This seems to be a bug, or is there something wrong with my setup?
Paul, is this the problem you are referring to?
Josias
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@gmail.com wrote:
> On Apr 12, 2005 5:14 AM, J. Wolfgang Kaltz
> <ka...@interactivesystems.info> wrote:
>
>>IMHO I don't think the CMS GUI language should have anything to do with
>>the content language. As a CMS user, I want to have the language I am
>>used to, independently of the current content.
>>Example: I am looking at the start page, for which a german and an
>>english version exists. I do not want the labels for the CMS menus to
>>change, depending on whether I'm currently working on the english, or
>>the german content.
>>Or am I misunderstanding the issue ?
>
>
> You understand, but there are several issues here:
> 1. Content language is chosen by visitors.
> 2. Site navigation is controlled FOR ALL VISITORS by the browser setting.
Hmmmm, I think I misunderstand something ...
The site navigation language is based on the document language which
is determined by the DocumentBuilder based on the URL. For instance
the DefaultDocumentBuilder chooses the default language if no suffix
"_*.html" is provided, otherwise the language denoted by the suffix.
> 3. The CMS maintainers want the CMS GUI to remain in the langauge of
> their choice regardless of the language of the content being edited.
> 4. The CMS GUI uses the same code as the Site navigation.
Does it? IIUC the CMS GUI uses the Cocoon i18n based on the {request:locale},
the content uses the {page-envelope:document-language} which is based on
the URL. Or am I missing something?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by so...@gmail.com.
On Apr 12, 2005 5:14 AM, J. Wolfgang Kaltz
<ka...@interactivesystems.info> wrote:
> IMHO I don't think the CMS GUI language should have anything to do with
> the content language. As a CMS user, I want to have the language I am
> used to, independently of the current content.
> Example: I am looking at the start page, for which a german and an
> english version exists. I do not want the labels for the CMS menus to
> change, depending on whether I'm currently working on the english, or
> the german content.
> Or am I misunderstanding the issue ?
You understand, but there are several issues here:
1. Content language is chosen by visitors.
2. Site navigation is controlled FOR ALL VISITORS by the browser setting.
3. The CMS maintainers want the CMS GUI to remain in the langauge of
their choice regardless of the language of the content being edited.
4. The CMS GUI uses the same code as the Site navigation.
Compromise?
- All site navigation should follow the visitor-chosen language.
- The CMS GUI should use the browser language.
So the modification in the top post should only be applied to the
publications. At least change the "default" publication since the
common (only?) method of creating new publications is to copy that
directory.
Or get the CMS GUI language setting from the Identity file for the
user. That requires another setting on the User screen.
> > I modified Lenya to choose the homepage based on the visitor's
> > browser's language. Standard Lenya uses the default language until
> > the visitor chooses another language.
>
> I agree that in theory, using the visitor's browser language would be
> the way to go. Unfortunately, in my experience few people set their
> browser language (I had written another cocoon-based software, where the ...
> Wolfgang
You state the browser language will always be English, and is useless
as information. That contradicts your earlier thoughts, and implies
Lenya should always follow the language chosen by the visitor.
Repeating from my last post:
*** Always ask "What will the visitor expect?" If the browser was set
to French, but the visitor chose to read in German, should the buttons
stay in French? Ask your favorite non-techie what they would expect.
***
That sums my thoughts about the language issue. Anyone know why Lenya
does not work in Tomcat if Tomcat is started by jsvc?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
solprovider@gmail.com schrieb:
> (...)
>
> My issue was the languages should never be different. Andreas
> mentioned that the Editor GUI uses i18n. I replied there were very
> few functions where an editor would not understand the language of the
> content being edited, and suggested an enhancement to remove one
> issue.
IMHO I don't think the CMS GUI language should have anything to do with
the content language. As a CMS user, I want to have the language I am
used to, independently of the current content.
Example: I am looking at the start page, for which a german and an
english version exists. I do not want the labels for the CMS menus to
change, depending on whether I'm currently working on the english, or
the german content.
Or am I misunderstanding the issue ?
>
> I modified Lenya to choose the homepage based on the visitor's
> browser's language. Standard Lenya uses the default language until
> the visitor chooses another language.
I agree that in theory, using the visitor's browser language would be
the way to go. Unfortunately, in my experience few people set their
browser language (I had written another cocoon-based software, where the
language presented is the browser setting - I thought this was the
obvious way to go at the time ;) ). In fact people are not aware of such
a setting; and when I tell them about it they typically don't want to
change it anyway.
So basically, people who download some browser have their
browser-language set to english, unless they download a special language
packaging, and they don't change the setting.
And from the controlled, company environments I've seen, most also
didn't change the browser-language setting in their internal software
packaging, so the typical user desktop browser is also set to english in
such environments.
So bottom-line, IMHO given the current state of Web browser usage, I
don't believe in using the browser-language setting as valid information.
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by so...@gmail.com.
On Apr 12, 2005 3:56 AM, Dave Sunerton-Burl <da...@lledr-solutions.co.uk> wrote:
> How about adding a "chosen language" field to the user details
> (initially generated from the browser language). That way, the content
> can be displayed in the browser language and the Lenya UI in the chosen
> language of the user (which will be the same unless they choose
> differently).
That is the reverse of the current situation. Standard Lenya allows
controlling the language of content using the URL, but all i18n
functions use the browser's language specification. i18n should be
used in the XSL for all website architecture. This means the content
is in the chosen language, but the "Go to next page" link is in the
browser's language.
My issue was the languages should never be different. Andreas
mentioned that the Editor GUI uses i18n. I replied there were very
few functions where an editor would not understand the language of the
content being edited, and suggested an enhancement to remove one
issue.
I modified Lenya to choose the homepage based on the visitor's
browser's language. Standard Lenya uses the default language until
the visitor chooses another language.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Dave Sunerton-Burl <da...@lledr-solutions.co.uk>.
Andreas Hartmann wrote:
> Paul wrote:
>
>>> 4. Fix the languages.
>>>
>
>
> [...]
>
>> Admin GUI: Is there any maintenance function that can be handled by
>> someone that
>> does not understand the language of the current document? The only
>> function I
>> noted is the creation of a new language version of a document. That
>> could be
>> avoided if document creation created every language version. (That
>> feature
>> would be a great time-saver for sites with many languages. The alternate
>> language versions can be removed if unneeded.)
>
>
> That's certainly worth an enhancement bug. What about a checkbox "create
> all
> language versions" on the create screen?
>
>
>> The titles need to be edited by
>> someone understanding both languages. Creation and publishing are
>> separate
>> events, so this does not affect production.
>>
>> Developers need to test features in languages they do not understand,
>> but they
>> should also be testing i18n. My solution was to replace the
>> cmsui_xx.xml files
>> with English versions with the language name before each translation:
>> <message key="Save">German Save</message>
>> (This might be automated for easier development.)
>>
>> I do not understand why i18n should not follow the document language.
>> What am I
>> missing?
>
>
> OK, I see your point, but I'm not sure if I agree :)
> What do the others think?
How about adding a "chosen language" field to the user details
(initially generated from the browser language). That way, the content
can be displayed in the browser language and the Lenya UI in the chosen
language of the user (which will be the same unless they choose
differently).
--
Dave Sunerton-Burl
Lledr Solutions
Email : dave@lledr-solutions.co.uk
Phone : +44 (0)1690 750446
Web : www.lledr-solutions.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Andreas Hartmann <an...@apache.org>.
Paul wrote:
>>4. Fix the languages.
>>
[...]
> Admin GUI: Is there any maintenance function that can be handled by someone that
> does not understand the language of the current document? The only function I
> noted is the creation of a new language version of a document. That could be
> avoided if document creation created every language version. (That feature
> would be a great time-saver for sites with many languages. The alternate
> language versions can be removed if unneeded.)
That's certainly worth an enhancement bug. What about a checkbox "create all
language versions" on the create screen?
> The titles need to be edited by
> someone understanding both languages. Creation and publishing are separate
> events, so this does not affect production.
>
> Developers need to test features in languages they do not understand, but they
> should also be testing i18n. My solution was to replace the cmsui_xx.xml files
> with English versions with the language name before each translation:
> <message key="Save">German Save</message>
> (This might be automated for easier development.)
>
> I do not understand why i18n should not follow the document language. What am I
> missing?
OK, I see your point, but I'm not sure if I agree :)
What do the others think?
>>>True security (forcing a login before allowing access) should be in
>>>the subtree-policy.acml under {pub}/config/ac/policies. The (new?)
>>>"Inheriting Policy Manager" will make this difficult unless a subtree
>>>can override a parent:
>>><ac:world><ac:role id="none"/></ac:world>
>>
>>Yes, this is a known and often discussed issue. We were a little hesitant
>>to implement subtractive policies because of the complexity. Suggestions
>>and patches are very welcome.
>
>
> Lenya builds a list of groups with associated roles for the subtree:
> - Start at the top level and add existing entries.
> - <ac:policy inherit="0">clears the list.
> - <ac:role id="none"/> removes all inherited roles from the Group.
> Then match the visitor's Groups against the list, and assign the roles.
>
> The easiest Admin GUI adds a checkbox for "Do not inherit access policies" that
> adds inherit="0". A GUI clearing specific Group's inheritance should not be
> difficult, but can be added later.
>
> (Optimize by checking from the bottom for the inherit property? It is probably
> faster to load from the top and clear the list than to load both directions,
> unless each level is cached from the bottom-up for use during top-down, which is
> easy in Java.)
Sounds reasonable. Would you mind filing an enhancement bug with this
specification?
Thanks again,
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Paul <so...@gmail.com>.
> 4. Fix the languages.
> > Lenya uses the language in the URL for content, but i18n uses the
> > browser's locale setting. Why display German content with French
> > buttons? All text should change if a visitor selects a different
> > language.
> It was a design decision to separate the CMS user language selection
> from the site visitor language selection. The site visitor language
> should depend on the URL to allow static serving of the site. The
> GUI language was separated to allow editing multiple language
> documents using a single language GUI.
We agree visitors should always see all content in the document language. Since
i18n should be used for multiple language sites, it must change with the content.
Editor GUI: Does the editor understand the language of the content they are
maintaining? Is the editor editing the text online, or are they pasting content
maintained outside Lenya? I believe normal usage is documents are maintained in
Lenya by a writer of the current language, so the language can change with the
content.
Admin GUI: Is there any maintenance function that can be handled by someone that
does not understand the language of the current document? The only function I
noted is the creation of a new language version of a document. That could be
avoided if document creation created every language version. (That feature
would be a great time-saver for sites with many languages. The alternate
language versions can be removed if unneeded.) The titles need to be edited by
someone understanding both languages. Creation and publishing are separate
events, so this does not affect production.
Developers need to test features in languages they do not understand, but they
should also be testing i18n. My solution was to replace the cmsui_xx.xml files
with English versions with the language name before each translation:
<message key="Save">German Save</message>
(This might be automated for easier development.)
I do not understand why i18n should not follow the document language. What am I
missing?
> > True security (forcing a login before allowing access) should be in
> > the subtree-policy.acml under {pub}/config/ac/policies. The (new?)
> > "Inheriting Policy Manager" will make this difficult unless a subtree
> > can override a parent:
> > <ac:world><ac:role id="none"/></ac:world>
> Yes, this is a known and often discussed issue. We were a little hesitant
> to implement subtractive policies because of the complexity. Suggestions
> and patches are very welcome.
Lenya builds a list of groups with associated roles for the subtree:
- Start at the top level and add existing entries.
- <ac:policy inherit="0">clears the list.
- <ac:role id="none"/> removes all inherited roles from the Group.
Then match the visitor's Groups against the list, and assign the roles.
The easiest Admin GUI adds a checkbox for "Do not inherit access policies" that
adds inherit="0". A GUI clearing specific Group's inheritance should not be
difficult, but can be added later.
(Optimize by checking from the bottom for the inherit property? It is probably
faster to load from the top and clear the list than to load both directions,
unless each level is cached from the bottom-up for use during top-down, which is
easy in Java.)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by Andreas Hartmann <an...@apache.org>.
Paul Ercolino wrote:
First of all, thanks for your constructive comments!
[...]
> 4. Fix the languages.
> Lenya uses the language in the URL for content, but i18n uses the
> browser's locale setting. Why display German content with French
> buttons? All text should change if a visitor selects a different
> language.
It was a design decision to separate the CMS user language selection
from the site visitor language selection. The site visitor language
should depend on the URL to allow static serving of the site. The
GUI language was separated to allow editing multiple language
documents using a single language GUI.
[...]
> Also, merge the {pub}/lenya/xslt into {pub}/xslt. Why do we need
> separate places for publication-specific XSL?
This was done to separate files which override the core using fallback
from the rest of the publication-specific XSL. In 1.4 this separation
is obsolete because publication templating works for all files.
[...]
> True security (forcing a login before allowing access) should be in
> the subtree-policy.acml under {pub}/config/ac/policies. The (new?)
> "Inheriting Policy Manager" will make this difficult unless a subtree
> can override a parent:
> <ac:world><ac:role id="none"/></ac:world>
Yes, this is a known and often discussed issue. We were a little hesitant
to implement subtractive policies because of the complexity. Suggestions
and patches are very welcome.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for
Developers)
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-04-10 at 17:06 -0400, Paul Ercolino wrote:
<snip cheers for the feedback/>
>
>
> --
> The http://lenya.apache.org/community/mailing-lists.html does not give
> the email address for the user mailing list. The dev address is tiny
> at the bottom.
>
see the section "Subscribe/Unsubscribe". You are not subscribed to the
list, I moderated your message. Please subscribe.
> Will the developers notice this here?
Yeah all devs are as well subscribed to the user list.
> Should I send these items to the
> dev mail list? Do I need to register with the Bugzilla?
Yeah, that is always a good idea if you plan to use and enhance lenya.
Cheers for the feedback
salu2
thorsten
> None of
> these issues were mentioned in Bugzilla.
>
> Helpfully,
> solprovider
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Helpful Notes about Installation (and Suggestions for Developers)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Paul Ercolino wrote:
> Will the developers notice this here? Should I send these items to the
> dev mail list? Do I need to register with the Bugzilla? None of
> these issues were mentioned in Bugzilla.
thanks for these.. will respond in detail.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org