I tried, but the various "getTranslated" method return exactly the same document instance as the one they are called on. Because the document is not yet translated. They all seems to work in the model "is translation exist, return it. Otherwise return the default document", which is not what i am looking for.
----- Mail original -----
De: "Clemens Klein-Robbenhaar" <c.robbenhaar(a)espresto.com>
À: "users" <users(a)xwiki.org>
Envoyé: Lundi 15 Décembre 2014 18:54:04
Objet: Re: [xwiki-users] setting translation from groovy
Hi,
just a quick response ... I have not really tried, but as far as I remember something like:
translatedDoc = newDoc.getTranslatedDocument(language)
should work.
The explanation is that translations of given document are not completely different documents (so you do not have to make a copy to create them),
but instead "variants" of the document in the default language, so you can access them directly from the document itself
HTH
Clemens
On 12/15/2014 12:01 PM, David Delbecq wrote:
> Hello,
>
> say i want to create a new Xwikidocument in groovy, and i want this document to already have two languages. I tried to use this code in groovy and various other variants, but xwiki keep creating a single version of document, with content in last language of loop and default language in the default locale of user executing script. It's just ignoring any tip on local. How can I set translations?
>
> Note: my final purpose is so that a user can upload 2 versions of a odt file in a form, and i will automatically load it in the concerned translations. Setting translation content is the last bit i am missing. I can't find any method in xwiki api that says "here is content translated in language xx" :/
>
>
> newDoc = xwiki.getDocument(new DocumentReference("xwiki","Memorandum","Memo-1234","en"));
> newDoc.getDocument().setDefaultLanguage(defaultLanguage);
> referenceDocument = "Memorandum.Memo-"+number
> for (language in ["fr","nl","en"]){
> if (title[language] !=null && title[language].trim().length()>0){
> println("new document in "+language)
> translatedDoc = new Document(
> newDoc.getDocument().copyDocument(
> new DocumentReference("xwiki","Memorandum","Memo-1234",language),
> xcontext.getContext()),
> xcontext.getContext())
> translatedDoc.setContent("Hello in "+language+": "+title[language])
> translatedDoc.save();
> }
> }
>
>
> Any advice would be greatly welcomed
> David Delbecq
>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
mit freundlichen Grüßen
Clemens Klein-Robbenhaar
--
Clemens Klein-Robbenhaar
Software Development
EsPresto AG
Breite Str. 30-31
10178 Berlin/Germany
Tel: +49.(0)30.90 226.763
Fax: +49.(0)30.90 226.760
robbenhaar(a)espresto.com
HRB 77554 B - Berlin-Charlottenburg
Vorstand: Maya Biersack, Peter Biersack
Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber
Zertifiziert nach ISO 9001:2008
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Hello,
say i want to create a new Xwikidocument in groovy, and i want this document to already have two languages. I tried to use this code in groovy and various other variants, but xwiki keep creating a single version of document, with content in last language of loop and default language in the default locale of user executing script. It's just ignoring any tip on local. How can I set translations?
Note: my final purpose is so that a user can upload 2 versions of a odt file in a form, and i will automatically load it in the concerned translations. Setting translation content is the last bit i am missing. I can't find any method in xwiki api that says "here is content translated in language xx" :/
newDoc = xwiki.getDocument(new DocumentReference("xwiki","Memorandum","Memo-1234","en"));
newDoc.getDocument().setDefaultLanguage(defaultLanguage);
referenceDocument = "Memorandum.Memo-"+number
for (language in ["fr","nl","en"]){
if (title[language] !=null && title[language].trim().length()>0){
println("new document in "+language)
translatedDoc = new Document(
newDoc.getDocument().copyDocument(
new DocumentReference("xwiki","Memorandum","Memo-1234",language),
xcontext.getContext()),
xcontext.getContext())
translatedDoc.setContent("Hello in "+language+": "+title[language])
translatedDoc.save();
}
}
Any advice would be greatly welcomed
David Delbecq
Hi!
The default displayer for users is failing with guest (http://jira.xwiki.org/browse/XWIKI-11472)
Fix shown in this issue works fine for colibri skin, but fails for flamingo. Does anyone have a solution?
Kind regards,
Dmitry
Hi,
First, sorry for my bad english.
I've got an issue when i want to import a XAR file (size : 53 mb). When i
want to import it, i've got an error message who said that max size for the
import is 32 Mb.
I understood the the WikiStream allowed to import files of any size.
So can you explain me why i've got a limit and, if it's possible, how i can
bypass them.
Thanks.
Kevin.
--
View this message in context: http://xwiki.475771.n2.nabble.com/Xwiki-6-3-issue-when-import-xar-file-larg…
Sent from the XWiki- Users mailing list archive at Nabble.com.
I have a groovy script that takes an array of table data and formats it in a table as follows. As you can see, I'd like to wrap the table in a form.
{{groovy}}
// [... supplied with array of 2-element arrays...]
println "{{html}}"
println "<form action=\"\" name=\"chooseForm\" method=post>"
println "<input type=hidden name=\"step\" value=\"choose\" /><input type=hidden name=\"form_token\" value=\"${services.csrf.getToken()}\" />"
println "{{/html}}"
println '|= |= Col 1|= Col2'
int lineNo = 0;
for (row in rows) {
if(lineNo!=0) { // Skip first (header) line
print "| {{html}}<input type=checkbox checked=\"checked\" name=\"choose${lineNo}\" form=\"chooseForm\" />{{/html}}"
print "| {{html}}<input type=text name=\"col1_${lineNo}\" form=\"chooseForm\" value=\"${row[0]}\"/>{{/html}}"
print "| {{html}}<input type=text name=\" col2_${lineNo}\" form=\"chooseForm\" value=\"${row[1]}\" />{{/html}}"
print '\n'
}
++lineNo;
}
print "| {{html}}<input type=submit /></form>{{/html}}"
{{/groovy}}
The problem is that the first {{html}} block closes the form before the table is started. Note that I have tried using ##form="chooseForm"## in the inputs within the table to associate them with the form, but this didn't work, at least with Firefox, since the data for these inputs does not get included in the POST content. Obviously I could use Javascript to modify the form, but I was aiming for a JS-free solution. Any ideas?
Hi everyone,
= Short Story =
I propose to change the behaviour of the top level menu from Flamingo
for tablet and desktop screens (so NOT for phones) to match the
behaviour we had in 6.2 BUT improving the separation between the
navigation links and the drop down toggle. The idea is that the top
level menu entries should behave like a drop down button (e.g. the Add
button) but without looking like one. You can see some screen shots at
http://jira.xwiki.org/browse/XWIKI-11517.
= Long Story =
I've heard complains that the current behaviour of the top level menu
from Flamingo skin is not perfect. The issue is that you need to click
twice to navigate. Ok, with a mouse you can use the middle click
(wheel) to open the link in a new tab but still it's annoying for
simple uses and for those that use the touch pad or a tablet.
An alternative I have investigated in
http://jira.xwiki.org/browse/XWIKI-11479 is to open the menu on hover
(on devices that support this of course). The result is quite nice and
effective but there is a problem: if you have a second horizontal menu
displayed under the top level menu then you'll have a hard time
hovering the second menu. So I decided to close XWIKI-11479 as Won't
Fix. For those that like the open-on-hover behaviour and which don't
plan to use a second menu I've published this extension
http://extensions.xwiki.org/xwiki/bin/view/Extension/Hover+and+Default+Acti…
.
The other alternative to fix the problem is to go back to the
behaviour from 6.2. Precisely, each menu has two sides:
* on the left is the label which is a link used for navigation
* on the right there is a toggle (arrow) used to open the menu.
The problem with this, and the reason we change it in 6.3, was that
the label and the toggle were not separated very well so the user
could easily think they were doing the same action (opening the menu).
At the same time this separation felt unnatural on extra small screens
(phones) because you couldn't tap easily on the toggle (arrow).
The solution I propose is to:
* Keep the current behaviour for extra small screens (phones). That
means the use has to tap twice to navigate: one tap to open the menu
and another one on the "Go to this XYZ".
* On desktop and tablet enable the default action (navigation link) as
in 6.2 but improve the separation so that the menu behaves as much as
possible as a drop down button (e.g. the Add button) without looking
like one. This means:
** You should understand there are two sides without hovering
** Separate hover and active state (e.g. the link is not hovered when
the toggle is hovered)
I've investigated *many* ways to achieve this and the result can be
seen on http://jira.xwiki.org/browse/XWIKI-11517. This is close to
http://extensions.xwiki.org/xwiki/bin/view/Extension/Enable+Default+Action+…
but not the same.
NOTE: The way the menu behaves and looks on hover and click (text and
background color) is strictly determined by the color theme. Some
themes highlight the hovered menu items by changing their background
color, others the text color and some do both. My changes are
independent on this. We can of course improve the default color theme
to better highlight the menu items. This is a different topic though.
I'd like to commit this changes in 6.4. Here's my +1.
Thanks,
Marius
Hello - is it possible to enable searching of additional filetypes within XWiki 6.2.4? Specifically I would like to be able to search attachments that are 7-Zip .7z archives. It looks to me as though the underlying library (Commons Compress) supports this filetype, but I am a new XWiki user and non-java programmer so I may be assuming too much.
Thanks in advance for your thoughts on this -
Garth Arnold
________________________________
GHC Confidentiality Statement
This message and any attached files might contain confidential information protected by federal and state law. The information is intended only for the use of the individual(s) or entities originally named as addressees. The improper disclosure of such information may be subject to civil or criminal penalties. If this message reached you in error, please contact the sender and destroy this message. Disclosing, copying, forwarding, or distributing the information by unauthorized individuals or entities is strictly prohibited by law.
Hi,
Using XWiki Enterprise 5.2, standalone install. We notice dots (.) in
page titles are escaped in HSQLDB (e.g. when I cat the contents of
xwiki_db.log and grep something particular in the article I'm seeking) :
INSERT INTO XWIKIDOC VALUES(...,'Ressources.Some page title with
accented characters in French (2007)\. Plan de rel\u00e8ve bla bla de
salle d''op\u00e9ration',
We can see all accented characters and special characters like the
apostrophe in the last word ("d'opération") are escaped, but then the
dot in the title next to "(2007)" gets escaped too.
I guess the reason it is escaped in the title is that the dot is used as
a separator for the wiki hierarchy (Resources.Some page really is like
the directory structure in our XWiki instance, that is Ressources/Some
page). Is that so ? Can we change that behaviour or do I have to tell
my users to stop using dots (and possibly other special characters ?) in
page titles ?
Thanx for pointers,
Yves Moisan
I think the problem has more to do with the FileUploadPlugin returning an array containing entries for all form field items, not just the file inputs. Also, the FileItem getFile(FormFieldName) method in the plugin is not exposed in the FileUploadPlugin API, so I had to resort to getting the whole List<FileItem> and iterating through to finding one with a matching field instead of assuming I knew the correct index.
I'm keeping my fingers crossed that the XWiki folks don't start using one-based arrays </shudder>
> -----Original Message-----
> From: Hamster [mailto:teunham@hotmail.com]
> Sent: Tuesday, 9 December 2014 9:04 PM
> To: users(a)xwiki.org
> Subject: Re: [xwiki-users] Reading a file submitted from a form
>
> The joy of zero-based vs one-based arrays :-)
>