[xwiki-devs] Issue with the document translation bundle created by AWM
Hi devs, In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope). The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched. So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered. The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me. WDYT I should do for 4.5: (1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :) Thanks, Marius
Most of the work is about adding space support to https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... then all features based on component registration will be bale to benefit from it (UIX, translations, wiki macros, etc...). On Localization side what would be the required right to register a translation to a whole space ? On Tue, Jan 22, 2013 at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, Jan 23, 2013 at 10:08 AM, Thomas Mortagne <[email protected]> wrote:
Most of the work is about adding space support to https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... then all features based on component registration will be bale to benefit from it (UIX, translations, wiki macros, etc...).
On Localization side what would be the required right to register a translation to a whole space ?
I vote for space administration right, as minimum requirement. Thanks, Marius
On Tue, Jan 22, 2013 at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case. Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround. Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context. It would be intermediary between page and space scopes. WDYT? Thanks -Vincent
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol <[email protected]> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context.
You are just describing what on demand means and it's what Marius is using.
It would be intermediary between page and space scopes.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol <[email protected]> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context.
You are just describing what on demand means and it's what Marius is using.
And which doesn't work for live tables because the live table rows are retrieved in separate (AJAX) requests and thus you need a custom live table results page if you need to "demand" the document translation bundle on those requests too. Thanks, Marius
It would be intermediary between page and space scopes.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jan 24, 2013, at 9:04 AM, Marius Dumitru Florea <[email protected]> wrote:
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol <[email protected]> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context.
You are just describing what on demand means and it's what Marius is using.
And which doesn't work for live tables because the live table rows are retrieved in separate (AJAX) requests and thus you need a custom live table results page if you need to "demand" the document translation bundle on those requests too.
ah ok, got it! So what we would need ideally is a Session scope which would be explicitly started/stopped. It would mean storing the CM data either in the application context or in the HTTP Session (probably better since it can expire even if the code forgets to close the session explicitly). I'd say both are valid, the Session is a little bit cleaner I feel but possibly slightly more complex to use for a small advantage. Thanks -Vincent
Thanks, Marius
It would be intermediary between page and space scopes.
WDYT?
Thanks -Vincent
On 01/24/2013 03:44 AM, Vincent Massol wrote:
On Jan 24, 2013, at 9:04 AM, Marius Dumitru Florea <[email protected]> wrote:
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol <[email protected]> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context.
You are just describing what on demand means and it's what Marius is using.
And which doesn't work for live tables because the live table rows are retrieved in separate (AJAX) requests and thus you need a custom live table results page if you need to "demand" the document translation bundle on those requests too.
ah ok, got it!
So what we would need ideally is a Session scope which would be explicitly started/stopped. It would mean storing the CM data either in the application context or in the HTTP Session (probably better since it can expire even if the code forgets to close the session explicitly).
I'd say both are valid, the Session is a little bit cleaner I feel but possibly slightly more complex to use for a small advantage.
This looks like a bit of overkill to me. The way it's been done for ColorThemes, for example, is to pass the current theme name in the ssx.use call. We could do the same, explicitly in the AWM generated homepages: $xwiki.jsx.use('livetable', {'bundle': currentAppBundleName}) Another option is to redesign how JS L10N works. Currently we're including translations in the JS file, by parsing $msg.get calls in the JS source. Most of the other libraries use a separate resource file and dynamic calls to interpolate strings.
Thanks -Vincent
Thanks, Marius
It would be intermediary between page and space scopes.
WDYT?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
On Thu, Jan 24, 2013 at 5:31 PM, Sergiu Dumitriu <[email protected]> wrote:
On 01/24/2013 03:44 AM, Vincent Massol wrote:
On Jan 24, 2013, at 9:04 AM, Marius Dumitru Florea <[email protected]> wrote:
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol <[email protected]> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope).
The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched.
So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered.
The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me.
WDYT I should do for 4.5:
(1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context.
You are just describing what on demand means and it's what Marius is using.
And which doesn't work for live tables because the live table rows are retrieved in separate (AJAX) requests and thus you need a custom live table results page if you need to "demand" the document translation bundle on those requests too.
ah ok, got it!
So what we would need ideally is a Session scope which would be explicitly started/stopped. It would mean storing the CM data either in the application context or in the HTTP Session (probably better since it can expire even if the code forgets to close the session explicitly).
I'd say both are valid, the Session is a little bit cleaner I feel but possibly slightly more complex to use for a small advantage.
This looks like a bit of overkill to me.
The way it's been done for ColorThemes, for example, is to pass the current theme name in the ssx.use call. We could do the same, explicitly in the AWM generated homepages:
$xwiki.jsx.use('livetable', {'bundle': currentAppBundleName})
Another option is to redesign how JS L10N works. Currently we're including translations in the JS file, by parsing $msg.get calls in the JS source. Most of the other libraries use a separate resource file and dynamic calls to interpolate strings.
OK, let's explain for the third time :) It's not about JavaScript code. It could be a problem in the future but it's not a problem now. My problem is with the live table results page (XWiki.LiveTableResults). The live table results need to be translated sometimes, so I need the application document bundle to be enabled when the live table requests its rows. The way to do this it to either (1) have the document translation bundle enabled for a scope (space, wiki, etc.) that includes the live table results page or (2) demand the document translation bundle in the live table results page (thus have a custom results page!). Thanks, Marius
Thanks -Vincent
Thanks, Marius
It would be intermediary between page and space scopes.
WDYT?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 01/24/2013 12:39 PM, Marius Dumitru Florea wrote:
On Thu, Jan 24, 2013 at 5:31 PM, Sergiu Dumitriu <[email protected]> wrote:
On 01/24/2013 03:44 AM, Vincent Massol wrote:
On Jan 24, 2013, at 9:04 AM, Marius Dumitru Florea <[email protected]> wrote:
On Wed, Jan 23, 2013 at 9:29 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Jan 23, 2013 at 6:50 PM, Vincent Massol <[email protected]> wrote:
On Jan 22, 2013, at 7:15 PM, Marius Dumitru Florea <[email protected]> wrote:
> Hi devs, > > In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to > choose between using the document translation bundle on demand (only > when needed) and using it automatically (in some scope). > > The problem with on demand is that if you have a live table you need a > custom live table results page just to demand the translation bundle > when live table results are fetched. > > So I decided to use wiki scope, but, as it turns out, you need special > rights to register a document translation bundle on the entire wiki. A > simple user creating an application with AWM won't have the > application translation bundle registered. > > The reason I choose the 'wiki' scope is that there was no 'space' > scope. Space (application) scope makes a lot of sense in my case and > I'm wondering if it's hard to implement it. Note that I already make > the application creator an admin of the application space, so > requiring space administration rights for space scope is fine for me. > > WDYT I should do for 4.5: > > (1) use the document translation on demand and generate a custom live > table results page or > (2) push for Thomas to implement space scope if it's simple :)
Implementing 2 is quite easy as Thomas pointed out. We didn't have the need till now for registering a component at the space level but it's a valid use case.
Now you don't really need space level if I understand correctly your use case. All you need is to have translations available for the generate application's home page (where the livetable is). Using a Space scope would be a workaround.
Ideally we would just need a Request scope so that a component can be visible during a full request. I guess it should not be that hard to implement either. We could just save the list of components registered for that request in the execution context.
You are just describing what on demand means and it's what Marius is using.
And which doesn't work for live tables because the live table rows are retrieved in separate (AJAX) requests and thus you need a custom live table results page if you need to "demand" the document translation bundle on those requests too.
ah ok, got it!
So what we would need ideally is a Session scope which would be explicitly started/stopped. It would mean storing the CM data either in the application context or in the HTTP Session (probably better since it can expire even if the code forgets to close the session explicitly).
I'd say both are valid, the Session is a little bit cleaner I feel but possibly slightly more complex to use for a small advantage.
This looks like a bit of overkill to me.
The way it's been done for ColorThemes, for example, is to pass the current theme name in the ssx.use call. We could do the same, explicitly in the AWM generated homepages:
$xwiki.jsx.use('livetable', {'bundle': currentAppBundleName})
Another option is to redesign how JS L10N works. Currently we're including translations in the JS file, by parsing $msg.get calls in the JS source. Most of the other libraries use a separate resource file and dynamic calls to interpolate strings.
OK, let's explain for the third time :)
It's not about JavaScript code. It could be a problem in the future but it's not a problem now. My problem is with the live table results page (XWiki.LiveTableResults). The live table results need to be translated sometimes, so I need the application document bundle to be enabled when the live table requests its rows. The way to do this it to either (1) have the document translation bundle enabled for a scope (space, wiki, etc.) that includes the live table results page or (2) demand the document translation bundle in the live table results page (thus have a custom results page!).
OK, I see, I thought it's the JS that processes the JSON returned by the results. Still, can't we append &bundle=xyz in the URL fetched? This means that the l10n manager also enables bundles specified in the request. The smelly part is that we have to manually push the bundle name around, but I think it's not that bad, since it allows to decide when bundles must be pushed, and doesn't add the requirement that users of the API must remember to start and close sessions. I dislike session-wide bundles since they can affect unrelated resources, since they practically become globally enabled, so why not just make them globally available from the start? Plus, when the parallelism of AJAX comes into play, it gets hard to properly find the end of the "session".
Thanks, Marius
Thanks -Vincent
Thanks, Marius
It would be intermediary between page and space scopes.
WDYT?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
participants (4)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol