Enhancements/Questions on Localization #7352

Open
HermesSbicego-Laser opened this Issue Oct 25, 2016 · 56 comments

Comments

Projects
None yet
6 participants
@HermesSbicego-Laser
Contributor

HermesSbicego-Laser commented Oct 25, 2016

Hi guys, I have a suggestion/question for you, related to how localization in Orchard works: in particular I would like to know which plans does the community have in order to improve it... some examples, to be more specific:

  1. Container/Containable items have no automations in order to keep container and containable items synchronized based on their culture
  2. Same for Taxonomies and terms, Taxonomy picker field, Content Picker Fileds and so on

It would be nice to have a site settings (or any more granular setting) that tells to our site/part/field what to do if it finds translated contents

We did something for taxonomies/terms/taxonomy field and ContentPickerField for 1.8.2; our approach unfortunately has some negative effects because we had to suppress some default behaviour of Orchard (drivers and handlers); for example a behaviour we had to override was in taxonomy: when a translation for a taxonomy is created the modules creates a new

taxnomy.Name + " Term"

content Type, so we had a proliferation of unnecessary ContentTypes "ProductTypeTerm", "TipoProdottiTerm", "TypesDeProduitsTerm", and we could not accept this effect (collateral effect due to how taxonomies was designed)...

However, being localization a crucial feature of CMS, we would like to know your opinion on that in order to plan our next steps

Another philosphical question: should be the Orchard.Localization Module manage how other modules should react with localizable related contents? Or should every module be designed to consistently manage localization?
Personally I prefer the second approach, maybe with some point of extension. Not sure how: IEventHandler called by LocalizationController? adding ContentPartDriver method?
What do you think?

Thank you for sharing your opinion with me.

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Oct 27, 2016

Member

I will setup a design meeting to talk about localization.

Member

sebastienros commented Oct 27, 2016

I will setup a design meeting to talk about localization.

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Oct 28, 2016

Contributor

@sebastienros , nice. We will partecipate, probably @MatteoPiovanelli-Laser and me. If it's possible we will prefer a date after November 4... tnks

Contributor

HermesSbicego-Laser commented Oct 28, 2016

@sebastienros , nice. We will partecipate, probably @MatteoPiovanelli-Laser and me. If it's possible we will prefer a date after November 4... tnks

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 2, 2016

Contributor

Hello. @sebastienros, is there any news on the discussion about localization?

Contributor

MatteoPiovanelli-Laser commented Nov 2, 2016

Hello. @sebastienros, is there any news on the discussion about localization?

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 2, 2016

Member

Is November 4th ok for everyone, anytime between 10am PST to 1pm PST (18 to 21 in Central Europe right now)

Member

sebastienros commented Nov 2, 2016

Is November 4th ok for everyone, anytime between 10am PST to 1pm PST (18 to 21 in Central Europe right now)

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@urbanit

This comment has been minimized.

Show comment
Hide comment
@urbanit

urbanit Nov 2, 2016

Contributor

It works for me.

Contributor

urbanit commented Nov 2, 2016

It works for me.

@urbanit

This comment has been minimized.

Show comment
Hide comment
@urbanit

urbanit Nov 2, 2016

Contributor

I mean 10am pst works for me...

Contributor

urbanit commented Nov 2, 2016

I mean 10am pst works for me...

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 2, 2016

Contributor

Ok 10am pst also works for me

Contributor

jersiovic commented Nov 2, 2016

Ok 10am pst also works for me

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 2, 2016

Contributor

To be sure we don't forget points that IMO are interesting here it is a list of needs that IMO is desirable localization solves:

LOCALIZATION NEEDS

  1. To localize data for some fields of a content item.

  2. To share unlocalized data between all cultures of a content item.

  3. To have permissions per culture (or unlocalized) of a content item.

  4. To be able of publishing and set author data only of one culture (or unlocalized)

  5. When localizing taxonomies that has exactly same terms for each culture but with translated captions:

    • a. To don't need one taxonomy type per culture
    • b. To be able of change the hierarchy of terms easily for all the cultures at the same time.
    • c. To be able of removing a term and its localized versions easily.
  6. To be able of query localized content items by culture through Projections and through Content Manager

  7. To be able of query content items filtering by its pointed localized content through Projections and through Content Manager (We need all localized contents of a pointed content is considered the same content).

    Example: You have a non-localizable BoatOffer type with:

    • A Content Picker field pointing to a localizable content items of Boat type.
    • A Taxonomy field pointing to a localizable term of a taxonomy.
      It is desirable Orchard out of the box allows us to filter boatoffers by a term of a localized taxonomy through Projections and through ContentManager without adding extra complexity.
  8. To be able of grouping content items by its pointed localized content.

    Example: For the previous example we need an efficient solution which provides BoatOffers grouped by pointed taxonomy term considering same term all those localized terms of the same term.

  9. Help to maintain things simple in scenarios where you reference localized content items.

Example: You have class OrderType containing OrderLines with content items ids pointing to content items of type Product. It is desirable code used to deal with Products (filter, group, access data) would be the same if Products is non localizable initially and in the future is changed to localizable. With current solution problem after you make Product localizable with another culture different than the one used by default is you need all products duplicated and need to deal with this duplication everywhere.
10. Allow to work with taxonomies with different hierarchies per culture.
11. Allow to work easily with content items that are not localized in all cultures.

LOCALIZATION SCENARIOS

  1. Contents that is expected they will have all its localized fields fulfilled for all the cultures of the site.
  2. Contents that are only available for certain cultures.
Contributor

jersiovic commented Nov 2, 2016

To be sure we don't forget points that IMO are interesting here it is a list of needs that IMO is desirable localization solves:

LOCALIZATION NEEDS

  1. To localize data for some fields of a content item.

  2. To share unlocalized data between all cultures of a content item.

  3. To have permissions per culture (or unlocalized) of a content item.

  4. To be able of publishing and set author data only of one culture (or unlocalized)

  5. When localizing taxonomies that has exactly same terms for each culture but with translated captions:

    • a. To don't need one taxonomy type per culture
    • b. To be able of change the hierarchy of terms easily for all the cultures at the same time.
    • c. To be able of removing a term and its localized versions easily.
  6. To be able of query localized content items by culture through Projections and through Content Manager

  7. To be able of query content items filtering by its pointed localized content through Projections and through Content Manager (We need all localized contents of a pointed content is considered the same content).

    Example: You have a non-localizable BoatOffer type with:

    • A Content Picker field pointing to a localizable content items of Boat type.
    • A Taxonomy field pointing to a localizable term of a taxonomy.
      It is desirable Orchard out of the box allows us to filter boatoffers by a term of a localized taxonomy through Projections and through ContentManager without adding extra complexity.
  8. To be able of grouping content items by its pointed localized content.

    Example: For the previous example we need an efficient solution which provides BoatOffers grouped by pointed taxonomy term considering same term all those localized terms of the same term.

  9. Help to maintain things simple in scenarios where you reference localized content items.

Example: You have class OrderType containing OrderLines with content items ids pointing to content items of type Product. It is desirable code used to deal with Products (filter, group, access data) would be the same if Products is non localizable initially and in the future is changed to localizable. With current solution problem after you make Product localizable with another culture different than the one used by default is you need all products duplicated and need to deal with this duplication everywhere.
10. Allow to work with taxonomies with different hierarchies per culture.
11. Allow to work easily with content items that are not localized in all cultures.

LOCALIZATION SCENARIOS

  1. Contents that is expected they will have all its localized fields fulfilled for all the cultures of the site.
  2. Contents that are only available for certain cultures.
@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 2, 2016

Contributor

This is my current view of the two solutions discussed by the moment in relation to the NEEDS defined previously. Maybe it is interesting for the Friday discussion.

LOCALIZATION SOLUTIONS

CulturePart pointing to related localized Content Items

Pros:

  • Allows Need 1 and Need 2 based on redundancy. Requires extra process for syncing unlocalized data between content items of each culture. Writes are less efficient.
  • Allows without extra work Need 4.
  • Allows without extra work Need 10.
  • Allows without extra work Need 11.

To-Do:

  • Need 3: Doesn't allow to set access permission per culture. Currently you can provide access to owner of a content item not by culture. We would need to implement a mechanism for enable that feature. If we want to controlate permissions for unlocalized fields, this solution doesn't fit with that need.

Cons:

  • Need 3: It doesn't provide solution for permissions, author and publishing of only unlocalized data.
  • Need 5: It doesn't provide solution for Need 5.b and 5.c. We would need to distinguish in some way taxonomies that have same hierarchy of terms for all its cultures from those that not. For the first ones Orchard should offer ways of managing them in as simpler way despite they are separated content items.
  • It doesn't provide a solution for Need 7 and Need 8 leaving the user and developer alone with this complexity. A possible solution can be to store always the master content item id in fields used for relate a content item with another.
    Problems are that extra accesses to db will be needed in this cases:
    • When saving a content item to get the master one.
    • When content item is rendered for showing the localized term with the same culture as the one required by the user. When you have 12 taxonomy fields in a content item those things matter.
  • It doesn't provide a solution for Need 9, so complexity arise to other parts of you app that are agnostic of orchard.

A content item contains all its localized data

Pros:

  • Allows Need 1 and Need 2 in a very simple and efficient way.
  • Allows without extra work Need 5.
  • Allows without extra work Need 6
  • Allows without extra work Need 7.
  • Allows without extra work Need 8.
  • Allows without extra work Need 9.
  • Allows without extra work Need 10 (if Need 4 is solved as commented in cons).
  • Allows without extra work Need 11 (if Need 4 is solved as commented in cons).

To-Do:

  • Need 3: As in previous solution we need a mechanism to set Permissions per culture at Role level. However If we want to controlate permissions for unlocalized fields, this solution fit very well with that need.

Cons:

  • For Need 4) we need to stablish a mechanism to set author and publication of data per culture within a content item. Maybe we need an extra table called ContentItemCultureRecord with PK(ContentItemId, CultureId) that contains columns Author and Published cultures.

When we edit a content item with localizable data through Admin UI we will see non localized data and localized data can be seen/edited using a combo to choose the culture in which we want to see those fields.

When editing a content item, those fields we don't have permissions to modify will appear in readonly mode.

-- EDITED --

Save and Publish buttons will store or Publish content item of only data in the culture for which the user has permissions. Only data of cultures with any non-blank data fulfilled will be marked as published. That means when you don't fulfill data for one culture that Content item won't be considered as published for that cultured.
Alternatively we can offer a setting at conten type level that mark its Content items always available for all cultures no matter what we fulfill when we store it.

Contributor

jersiovic commented Nov 2, 2016

This is my current view of the two solutions discussed by the moment in relation to the NEEDS defined previously. Maybe it is interesting for the Friday discussion.

LOCALIZATION SOLUTIONS

CulturePart pointing to related localized Content Items

Pros:

  • Allows Need 1 and Need 2 based on redundancy. Requires extra process for syncing unlocalized data between content items of each culture. Writes are less efficient.
  • Allows without extra work Need 4.
  • Allows without extra work Need 10.
  • Allows without extra work Need 11.

To-Do:

  • Need 3: Doesn't allow to set access permission per culture. Currently you can provide access to owner of a content item not by culture. We would need to implement a mechanism for enable that feature. If we want to controlate permissions for unlocalized fields, this solution doesn't fit with that need.

Cons:

  • Need 3: It doesn't provide solution for permissions, author and publishing of only unlocalized data.
  • Need 5: It doesn't provide solution for Need 5.b and 5.c. We would need to distinguish in some way taxonomies that have same hierarchy of terms for all its cultures from those that not. For the first ones Orchard should offer ways of managing them in as simpler way despite they are separated content items.
  • It doesn't provide a solution for Need 7 and Need 8 leaving the user and developer alone with this complexity. A possible solution can be to store always the master content item id in fields used for relate a content item with another.
    Problems are that extra accesses to db will be needed in this cases:
    • When saving a content item to get the master one.
    • When content item is rendered for showing the localized term with the same culture as the one required by the user. When you have 12 taxonomy fields in a content item those things matter.
  • It doesn't provide a solution for Need 9, so complexity arise to other parts of you app that are agnostic of orchard.

A content item contains all its localized data

Pros:

  • Allows Need 1 and Need 2 in a very simple and efficient way.
  • Allows without extra work Need 5.
  • Allows without extra work Need 6
  • Allows without extra work Need 7.
  • Allows without extra work Need 8.
  • Allows without extra work Need 9.
  • Allows without extra work Need 10 (if Need 4 is solved as commented in cons).
  • Allows without extra work Need 11 (if Need 4 is solved as commented in cons).

To-Do:

  • Need 3: As in previous solution we need a mechanism to set Permissions per culture at Role level. However If we want to controlate permissions for unlocalized fields, this solution fit very well with that need.

Cons:

  • For Need 4) we need to stablish a mechanism to set author and publication of data per culture within a content item. Maybe we need an extra table called ContentItemCultureRecord with PK(ContentItemId, CultureId) that contains columns Author and Published cultures.

When we edit a content item with localizable data through Admin UI we will see non localized data and localized data can be seen/edited using a combo to choose the culture in which we want to see those fields.

When editing a content item, those fields we don't have permissions to modify will appear in readonly mode.

-- EDITED --

Save and Publish buttons will store or Publish content item of only data in the culture for which the user has permissions. Only data of cultures with any non-blank data fulfilled will be marked as published. That means when you don't fulfill data for one culture that Content item won't be considered as published for that cultured.
Alternatively we can offer a setting at conten type level that mark its Content items always available for all cultures no matter what we fulfill when we store it.

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 3, 2016

Contributor

Please take a look to this interesting video from the Drupal community related with this topic:
Vimeo presents: Drupal 7/8 Content Translation models http://vimeo.com/27068202

Contributor

jersiovic commented Nov 3, 2016

Please take a look to this interesting video from the Drupal community related with this topic:
Vimeo presents: Drupal 7/8 Content Translation models http://vimeo.com/27068202

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 3, 2016

Contributor

Works also for me 10am pst.

Contributor

HermesSbicego-Laser commented Nov 3, 2016

Works also for me 10am pst.

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 4, 2016

Member

Meeting notes

default: en-US

Page content type With no fields (body, title, url)
Home page / -> en-US (id = 10) -> (Id=10 , TSId = 10)
Pagina de inicio /pagina-de-inicio -> es-ES (micId: 10) Id =11, TSId = 10
Pagina di inicia /pagina-di-inicia -> it-IT (micId: 10) Id =12, TSId = 10

Product, Title, Weight field, not localizable, Draftable

Motorbike -> Weight: 50kg -> Helmet
Motocicleta (es-ES) -> Weight: 50kg -> Casco
Motocicleta (it-IT) -> Weight: 50kg -> Casci

O1

Master content item id === Translation sets ids

  • Field localization doesn't work
    • Synchronize data across translation set
      • Question: Can we change it (a neutral) in any translation, can we display the value in every localization, or just on the main one
        • Yes -> propagates on "publish", and also updates all the drafts if any
      • If we rollback a localized item, we need to syncronize its fields also
      • Field Setting to mark it "culture neutral" / "non localizable"
      • Content handler to detect the fields, on publication/rollback
  • You can delete any translation independently
    • Unpublish master content item
  • How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)
    • We need to select the MCI id
  • The Content Item Picker field shows a drop down with all languages (can/should we store the MCId also?)
    • Option (Settings) to ensure the selected items have the same culture as the current culture
      • Sub-option to translate the selection automatically when a localized version is created
  • Should we localize menus
    • We can have different menus for each language, in text and in structure
    • Today we can create different menus, and use widget layers to render for each language
      • Solution: Add a LocalizationPart to Widgets, each widget in the Widgets Translation Set, will point to a different menu, when the widget is rendered, it will be filtered without the need of a Layer. It works today if you create new Widgets in different languages in different Translation sets, not by translating an existing widget (see bug #7347)
    • Optionally Be able to add a LocalizationPart to Menu and add a culture selector in the Menu editor using this part, so that synchronizing menus across languages is easier. It's independent from the previous item.
  • When a Clone is created to create a new localization, we should be able to customize the cloning event to create
    automatic translations. Example: Convert a Content Item Picker to its translation, or Taxonomy terms.
    • Add a property in the ClonedContentContext for the target culture

-- Different menu structures

"Menu English"
mi1, mi2

"Menu Italian"
mi1, mi2

(Localization Part to Menu Widget)

New Menu Widget

"English menu everywhere"
Menu -> Menu English
Localization part Culture -> English

New translation
"English menu everywhere"
Menu -> Menu Italian
Localization part Culture -> English

-- Same menu structure (TODO)
Translate menu items
Localization part to "Menu Items"

Taxonomies: Same as Menu items?


Issue, we only have a MSCId if the localization part is defined

Cid Mcid
1 1
2 2
3 2
4 NULL
5 NULL

  • Since 1.10 all master contents have their MCIds to 0, should it be the same id as the content item id.
Member

sebastienros commented Nov 4, 2016

Meeting notes

default: en-US

Page content type With no fields (body, title, url)
Home page / -> en-US (id = 10) -> (Id=10 , TSId = 10)
Pagina de inicio /pagina-de-inicio -> es-ES (micId: 10) Id =11, TSId = 10
Pagina di inicia /pagina-di-inicia -> it-IT (micId: 10) Id =12, TSId = 10

Product, Title, Weight field, not localizable, Draftable

Motorbike -> Weight: 50kg -> Helmet
Motocicleta (es-ES) -> Weight: 50kg -> Casco
Motocicleta (it-IT) -> Weight: 50kg -> Casci

O1

Master content item id === Translation sets ids

  • Field localization doesn't work
    • Synchronize data across translation set
      • Question: Can we change it (a neutral) in any translation, can we display the value in every localization, or just on the main one
        • Yes -> propagates on "publish", and also updates all the drafts if any
      • If we rollback a localized item, we need to syncronize its fields also
      • Field Setting to mark it "culture neutral" / "non localizable"
      • Content handler to detect the fields, on publication/rollback
  • You can delete any translation independently
    • Unpublish master content item
  • How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)
    • We need to select the MCI id
  • The Content Item Picker field shows a drop down with all languages (can/should we store the MCId also?)
    • Option (Settings) to ensure the selected items have the same culture as the current culture
      • Sub-option to translate the selection automatically when a localized version is created
  • Should we localize menus
    • We can have different menus for each language, in text and in structure
    • Today we can create different menus, and use widget layers to render for each language
      • Solution: Add a LocalizationPart to Widgets, each widget in the Widgets Translation Set, will point to a different menu, when the widget is rendered, it will be filtered without the need of a Layer. It works today if you create new Widgets in different languages in different Translation sets, not by translating an existing widget (see bug #7347)
    • Optionally Be able to add a LocalizationPart to Menu and add a culture selector in the Menu editor using this part, so that synchronizing menus across languages is easier. It's independent from the previous item.
  • When a Clone is created to create a new localization, we should be able to customize the cloning event to create
    automatic translations. Example: Convert a Content Item Picker to its translation, or Taxonomy terms.
    • Add a property in the ClonedContentContext for the target culture

-- Different menu structures

"Menu English"
mi1, mi2

"Menu Italian"
mi1, mi2

(Localization Part to Menu Widget)

New Menu Widget

"English menu everywhere"
Menu -> Menu English
Localization part Culture -> English

New translation
"English menu everywhere"
Menu -> Menu Italian
Localization part Culture -> English

-- Same menu structure (TODO)
Translate menu items
Localization part to "Menu Items"

Taxonomies: Same as Menu items?


Issue, we only have a MSCId if the localization part is defined

Cid Mcid
1 1
2 2
3 2
4 NULL
5 NULL

  • Since 1.10 all master contents have their MCIds to 0, should it be the same id as the content item id.
@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 7, 2016

Contributor

Hi,

@HermesSbicego-Laser and I debriefed offline a bit. We have some comments on what we discussed regarding the ContentPicker. Specifically, the following points from @sebastienros' notes:

How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)

  • We need to select the MCI id

The Content Item Picker field shows a drop down with all languages (can/should we store the MCId also?)

  • Option (Settings) to ensure the selected items have the same culture as the current culture
    • Sub-option to translate the selection automatically when a localized version is created

Adding the dropdown with the language selection in the "list" window that appears when clicking "Add" for a ContentPickerField is pretty straightforward, and does not actually require any dependency with the Orchard.Localization module (like it's done in the contents list view).

The Option and Sub-option I think will require a dependency from Orchard.Localization. To avoid introducing that dependency to the Orchard.ContentPicker feature (thus avoid back-compatibility issues) we would go and create another feature in the Orchard.ContentPicker module. Something along the lines of Orchard.ContentPickerLocalizationExtensions.
In that feature, we would add the settings we discussed, and the corresponding functionalities. A lot of those we actually have already as a custom extension we had built in O1.8, so it should not take too long to get a PR out for that.
Some questions remain for the sub-option:

  • When should the translation happen? I think it should be on a save/publish, since when we are doing the translation (click on the "new translation" link) we have not yet selected the target localization. Also, since the clone feature is not yet in 1.10.x, that should come later anyway.
  • How should we handle selected content items for which there is no translation? I would put a further setting to allow the users to choose whether they want to keep the content in the "wrong" language, or get rid of it (i.e. references to those items for which we find no pre-existing localization to the "correct" culture should be removed entirely, rather than replaced). The first case would be default for me.

That feature, as described, should pose no compatibility issue. I think it may not even have to change any existing code-files in the Orchard.ContentPicker module.

Tomorrow I will start working on this, because I have previous work we did to start from and adding the rest that we discussed should not be too much work. Any input and comments are appreciated.

Best,
Matteo

Contributor

MatteoPiovanelli-Laser commented Nov 7, 2016

Hi,

@HermesSbicego-Laser and I debriefed offline a bit. We have some comments on what we discussed regarding the ContentPicker. Specifically, the following points from @sebastienros' notes:

How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)

  • We need to select the MCI id

The Content Item Picker field shows a drop down with all languages (can/should we store the MCId also?)

  • Option (Settings) to ensure the selected items have the same culture as the current culture
    • Sub-option to translate the selection automatically when a localized version is created

Adding the dropdown with the language selection in the "list" window that appears when clicking "Add" for a ContentPickerField is pretty straightforward, and does not actually require any dependency with the Orchard.Localization module (like it's done in the contents list view).

The Option and Sub-option I think will require a dependency from Orchard.Localization. To avoid introducing that dependency to the Orchard.ContentPicker feature (thus avoid back-compatibility issues) we would go and create another feature in the Orchard.ContentPicker module. Something along the lines of Orchard.ContentPickerLocalizationExtensions.
In that feature, we would add the settings we discussed, and the corresponding functionalities. A lot of those we actually have already as a custom extension we had built in O1.8, so it should not take too long to get a PR out for that.
Some questions remain for the sub-option:

  • When should the translation happen? I think it should be on a save/publish, since when we are doing the translation (click on the "new translation" link) we have not yet selected the target localization. Also, since the clone feature is not yet in 1.10.x, that should come later anyway.
  • How should we handle selected content items for which there is no translation? I would put a further setting to allow the users to choose whether they want to keep the content in the "wrong" language, or get rid of it (i.e. references to those items for which we find no pre-existing localization to the "correct" culture should be removed entirely, rather than replaced). The first case would be default for me.

That feature, as described, should pose no compatibility issue. I think it may not even have to change any existing code-files in the Orchard.ContentPicker module.

Tomorrow I will start working on this, because I have previous work we did to start from and adding the rest that we discussed should not be too much work. Any input and comments are appreciated.

Best,
Matteo

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 7, 2016

Contributor

Hi,

I forgot to discuss a point in my previous comment.

How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)

  • We need to select the MCI id

I would like a bit more input on it, but this is what I have in my head:
This, I think, should again be enabled/controlled by a setting. I think it would override the "list" view, in the fact that it would remove the dropdown for language selection. The list would then only show a single item for each translation set.
Q: How should I handle contents with no localization part? Should I even show them at all? I would have a further setting here for this.
With this setting enabled, the choice of localization for the selected items is actually handled when displaying. The way I would go about this is I would process things in an alternate view (but that sounds inefficient) or more likely by overriding the OnGetDisplayShape handler.
Q: How should I handle the case where the desired localization is not available? I would do as for the sub-option (see my previous comment) and have another setting to allow the user to choose.

I will work on this functionality right after the things I discussed in my previous comment. Here as well, any input and comments are appreciated.

Best,
Matteo

Contributor

MatteoPiovanelli-Laser commented Nov 7, 2016

Hi,

I forgot to discuss a point in my previous comment.

How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)

  • We need to select the MCI id

I would like a bit more input on it, but this is what I have in my head:
This, I think, should again be enabled/controlled by a setting. I think it would override the "list" view, in the fact that it would remove the dropdown for language selection. The list would then only show a single item for each translation set.
Q: How should I handle contents with no localization part? Should I even show them at all? I would have a further setting here for this.
With this setting enabled, the choice of localization for the selected items is actually handled when displaying. The way I would go about this is I would process things in an alternate view (but that sounds inefficient) or more likely by overriding the OnGetDisplayShape handler.
Q: How should I handle the case where the desired localization is not available? I would do as for the sub-option (see my previous comment) and have another setting to allow the user to choose.

I will work on this functionality right after the things I discussed in my previous comment. Here as well, any input and comments are appreciated.

Best,
Matteo

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 7, 2016

Contributor

/cc @sebastienros @urbanit @jersiovic @MatteoPiovanelli-Laser
Hi all,
can we schedule next meeting for discussing open points on how localization should work in taxonomies/blogs/tags/etc? What about on Thursday 10am pst (18pm Central Europe) before triage meeting?

In the meanwhile I have a question for @sebastienros : We talked about "Culture Neutral Fields" but we didn't threat "Culture Neutral Parts": for parts things are more complex, I think it should be nice to have this feature too, maybe using or extending the cloning logic?

Contributor

HermesSbicego-Laser commented Nov 7, 2016

/cc @sebastienros @urbanit @jersiovic @MatteoPiovanelli-Laser
Hi all,
can we schedule next meeting for discussing open points on how localization should work in taxonomies/blogs/tags/etc? What about on Thursday 10am pst (18pm Central Europe) before triage meeting?

In the meanwhile I have a question for @sebastienros : We talked about "Culture Neutral Fields" but we didn't threat "Culture Neutral Parts": for parts things are more complex, I think it should be nice to have this feature too, maybe using or extending the cloning logic?

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 8, 2016

Contributor

I opened #7386 because things in the localization part work different than what I expected/remembered

Contributor

MatteoPiovanelli-Laser commented Nov 8, 2016

I opened #7386 because things in the localization part work different than what I expected/remembered

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 8, 2016

Contributor

#7388 adds the dropdown to select/filter by language in the view opened by the content picker field

Contributor

MatteoPiovanelli-Laser commented Nov 8, 2016

#7388 adds the dropdown to select/filter by language in the view opened by the content picker field

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 8, 2016

Contributor

In light of #7386, @HermesSbicego-Laser and I thougth that it's probably better to add a property TranslationSetId to LocalizationPart, as was initially proposed at the meeting (i do not remember who proposed it). That would have the value of the Id of the first ContentItem in a translation set.
All new logic would be built around that, without touching the existing ones that revolve around the MasterContentItemId, to avoid problems with existings modules that might be using that.
My idea is to never again use MasterContentItemId after that, but to leave it in for compatibility.

Contributor

MatteoPiovanelli-Laser commented Nov 8, 2016

In light of #7386, @HermesSbicego-Laser and I thougth that it's probably better to add a property TranslationSetId to LocalizationPart, as was initially proposed at the meeting (i do not remember who proposed it). That would have the value of the Id of the first ContentItem in a translation set.
All new logic would be built around that, without touching the existing ones that revolve around the MasterContentItemId, to avoid problems with existings modules that might be using that.
My idea is to never again use MasterContentItemId after that, but to leave it in for compatibility.

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 9, 2016

Contributor

Hi all,
our team de-de-briefed around previous meeting. we share our notes and considerations on ContentPickeField (we are working on it) and we tried to imagine a similar approach with taxonomies considering that we should not introduce breaking changes

De-briefing notes
Content Picker Field (CPF)

Options as discussed during online meeting
Otp1: Check culture integrity
Opt2 > Sub Opt1: Try to translate automatically

Scenario:
Opt1: true
Opt2: false

Problem: What to do with Untranslatable Contents (without LocalizationPart)?
possibility:
1. Keep them untouched, they live in CPF
2. Add Opt1.1 telling if this is an accepted behavior or not (not=Error on publish)

Scenario:
Otp1: true
Opt2: true

Problem: What happens if a translation is missing?
Possibility:
1. Keep them, save the content and notify it BUT this is nonsense for Opt1
A possible way is to threat Opt2 like an option, I mean not dependent from Opt1
SO
Options change
Opt1: ...
Opt2: ...
2. Remove them
But things change without user consent
3. Block the save/publish
This respect Opt1
4. Add an Opt3 telling what to do
SO
Options change
Opt1: ...
Opt2: ...
Opt3 > Sub Opt2 : Keep|Remove

We think we should take this approach, 'cause it supports all scenarios we talked till now
So, next in CPF Orchard Module, respecting but also extending the design:
Opt1: Try Translate (default true)
Opt1.1: Unselect item if translation is missing (default false)
Opt1.2: Unselect item if it's neutral (default false)
Opt2: Ensure language are the same (default false)
Opt2.1: Ensure selection of a culture neutral item is invalid (default false), i.e. you need to select a localizable content item

Update
Optionally: Display a drop down in front of the selector to translate the current selection in any other language.

Example
make a translation to IT(Itinerary IT)
Related POIS (CPF)
> Poi1 IT
> Poi2 en > want keep
> Video (culture neutral) > want remove
> Poi3 IT

Opt1: true (want to translate)
Opt1.1: false (want to keep untranslated)
Opt1.2: true (want to remove culture neutral)
Opt2: false (want to keep untranslated)
Opt2.1: false (as parent)


Taxonomy
How Craft CMS works
Taxonomies == Categories

Categories are:

  1. Hierarchical
  2. Are Culture Neutral
  3. Terms are Localizable
    3a. When first term is created all localized version are created
    3b. When adding a language, a job adds all localized versions in each term
    3c. Hierarchy is automatically syncronized too
  4. Taxonomy Field has setting to choose if:
    4a. Keep in sync with container
    4b. Force a locale

Problems with this approach
Can’t manage different hierarchy for different locales
Example:
In Europe e can sell french cheese
In USA we can’t sell french cheese

Q: Do we really want to force this behaviour in Orchard?
A: Our position is NO, cause it's wiil limit something that now is flexible

Creating automatically Localized version is not orchard default for the other contents

Problems in current Orchard behaviours
When a translation for a taxonomy is created the module creates a new taxnomy.Name + " Term" content Type, so we had a proliferation of unnecessary ContentTypes "ProductTypeTerm", "TipoProdottiTerm", "TypesDeProduitsTerm", and we could not accept this effect (collateral effect due to how taxonomies was designed)...
If you attach LocalizationPart to the 'xyz Terms Type' things do not work bacause when you make a translation

Proposed approach
LocalizationPart attached to taxonomy (Is optional)
LocalizationPartAttached automatically to “all xyz Term” Types, defined into a Site Setting

Taxonomy translation (obviously only if I have the LocalizationPart)
Example
Tax IT > Create “Tax IT Term” Type (if removes is soft deleted so we can always discover type)
> I do Translate
> Tax EN > it should not create “Tax EN Term” type but it should use “Tax IT Term” as Type

Corner case:

Q: What happens if I attach LocalizationPart on Taxonomy, later?
A: When I save a Taxonomy, It should move (and only move) only Terms of same locale to keep Locale in sync

Term translation (obviously only if I have the LocalizationPart)
Example

Tax IT > create Term:
If Term lang != Tax lang
If exists parent in same language > it should Change parent to localized parent
If does not exist parent in same language >
Dont save OR
Save as root (You can always move it to its parent later)
Should move term in the taxonomywith the same lang
If found > it does it
If not found translated taxonomy> throw an exception (AddModelError)
If Taxonomyis Culture neutral (LocalizationPart is missing) > Attach to neutral Taxonomy
TODO next: What happens when I move a Term?
Should I move also their translation version?
Keep the choice to the user? With a checkbox Try to keep hierarchy in sync

TaxonomyField translation
TaxonomyField has a TaxonomySource defined in the TaxonomyFieldSetting

Settings

Opt1: Try Translate (default true)

On creating
TaxonomyField
> I don’t know the lang so it exposes Taxonomy terms defined in field settings (as is)
On editing of a Content
TaxonomyField

If Opt1 == true > Should expose Taxonomy terms of same lang of content

If Taxonomyis translatable >

    if Has Translation, Change Taxonomy
    if Has no Translation, it sets taxonomy source to null, Warning on UI as is

If Taxonomyis not translatable > Keep Taxonomy

If terms are translatable >filter Taxonomy Terms on language
else >as is

If Opt1 == false > it exposes Taxonomy terms defined in field settings (as is)

On Saving Content
Taxonomy Field

If Opt1 == true && (Terms are Translatable || Taxonomy is Translatable) && ContentItem Is Translatable ==> Try to translate terms and removes them if missing

else ==> saves terms (as is)

Problems with current UI
When Autocomplete && User can create new terms
Our idea is: User Can create new terms only if “xyz Term” is Culture neutral


Blog/BlogPosts
Using same approach of Taxonomies/Terms.

If locale of Blog and BlogPost are not the same, tries to move BlogPost under a the right Blog translation but if it can't leave things untouched.


Tags
TBD


Container/Containable
TBD

Contributor

HermesSbicego-Laser commented Nov 9, 2016

Hi all,
our team de-de-briefed around previous meeting. we share our notes and considerations on ContentPickeField (we are working on it) and we tried to imagine a similar approach with taxonomies considering that we should not introduce breaking changes

De-briefing notes
Content Picker Field (CPF)

Options as discussed during online meeting
Otp1: Check culture integrity
Opt2 > Sub Opt1: Try to translate automatically

Scenario:
Opt1: true
Opt2: false

Problem: What to do with Untranslatable Contents (without LocalizationPart)?
possibility:
1. Keep them untouched, they live in CPF
2. Add Opt1.1 telling if this is an accepted behavior or not (not=Error on publish)

Scenario:
Otp1: true
Opt2: true

Problem: What happens if a translation is missing?
Possibility:
1. Keep them, save the content and notify it BUT this is nonsense for Opt1
A possible way is to threat Opt2 like an option, I mean not dependent from Opt1
SO
Options change
Opt1: ...
Opt2: ...
2. Remove them
But things change without user consent
3. Block the save/publish
This respect Opt1
4. Add an Opt3 telling what to do
SO
Options change
Opt1: ...
Opt2: ...
Opt3 > Sub Opt2 : Keep|Remove

We think we should take this approach, 'cause it supports all scenarios we talked till now
So, next in CPF Orchard Module, respecting but also extending the design:
Opt1: Try Translate (default true)
Opt1.1: Unselect item if translation is missing (default false)
Opt1.2: Unselect item if it's neutral (default false)
Opt2: Ensure language are the same (default false)
Opt2.1: Ensure selection of a culture neutral item is invalid (default false), i.e. you need to select a localizable content item

Update
Optionally: Display a drop down in front of the selector to translate the current selection in any other language.

Example
make a translation to IT(Itinerary IT)
Related POIS (CPF)
> Poi1 IT
> Poi2 en > want keep
> Video (culture neutral) > want remove
> Poi3 IT

Opt1: true (want to translate)
Opt1.1: false (want to keep untranslated)
Opt1.2: true (want to remove culture neutral)
Opt2: false (want to keep untranslated)
Opt2.1: false (as parent)


Taxonomy
How Craft CMS works
Taxonomies == Categories

Categories are:

  1. Hierarchical
  2. Are Culture Neutral
  3. Terms are Localizable
    3a. When first term is created all localized version are created
    3b. When adding a language, a job adds all localized versions in each term
    3c. Hierarchy is automatically syncronized too
  4. Taxonomy Field has setting to choose if:
    4a. Keep in sync with container
    4b. Force a locale

Problems with this approach
Can’t manage different hierarchy for different locales
Example:
In Europe e can sell french cheese
In USA we can’t sell french cheese

Q: Do we really want to force this behaviour in Orchard?
A: Our position is NO, cause it's wiil limit something that now is flexible

Creating automatically Localized version is not orchard default for the other contents

Problems in current Orchard behaviours
When a translation for a taxonomy is created the module creates a new taxnomy.Name + " Term" content Type, so we had a proliferation of unnecessary ContentTypes "ProductTypeTerm", "TipoProdottiTerm", "TypesDeProduitsTerm", and we could not accept this effect (collateral effect due to how taxonomies was designed)...
If you attach LocalizationPart to the 'xyz Terms Type' things do not work bacause when you make a translation

Proposed approach
LocalizationPart attached to taxonomy (Is optional)
LocalizationPartAttached automatically to “all xyz Term” Types, defined into a Site Setting

Taxonomy translation (obviously only if I have the LocalizationPart)
Example
Tax IT > Create “Tax IT Term” Type (if removes is soft deleted so we can always discover type)
> I do Translate
> Tax EN > it should not create “Tax EN Term” type but it should use “Tax IT Term” as Type

Corner case:

Q: What happens if I attach LocalizationPart on Taxonomy, later?
A: When I save a Taxonomy, It should move (and only move) only Terms of same locale to keep Locale in sync

Term translation (obviously only if I have the LocalizationPart)
Example

Tax IT > create Term:
If Term lang != Tax lang
If exists parent in same language > it should Change parent to localized parent
If does not exist parent in same language >
Dont save OR
Save as root (You can always move it to its parent later)
Should move term in the taxonomywith the same lang
If found > it does it
If not found translated taxonomy> throw an exception (AddModelError)
If Taxonomyis Culture neutral (LocalizationPart is missing) > Attach to neutral Taxonomy
TODO next: What happens when I move a Term?
Should I move also their translation version?
Keep the choice to the user? With a checkbox Try to keep hierarchy in sync

TaxonomyField translation
TaxonomyField has a TaxonomySource defined in the TaxonomyFieldSetting

Settings

Opt1: Try Translate (default true)

On creating
TaxonomyField
> I don’t know the lang so it exposes Taxonomy terms defined in field settings (as is)
On editing of a Content
TaxonomyField

If Opt1 == true > Should expose Taxonomy terms of same lang of content

If Taxonomyis translatable >

    if Has Translation, Change Taxonomy
    if Has no Translation, it sets taxonomy source to null, Warning on UI as is

If Taxonomyis not translatable > Keep Taxonomy

If terms are translatable >filter Taxonomy Terms on language
else >as is

If Opt1 == false > it exposes Taxonomy terms defined in field settings (as is)

On Saving Content
Taxonomy Field

If Opt1 == true && (Terms are Translatable || Taxonomy is Translatable) && ContentItem Is Translatable ==> Try to translate terms and removes them if missing

else ==> saves terms (as is)

Problems with current UI
When Autocomplete && User can create new terms
Our idea is: User Can create new terms only if “xyz Term” is Culture neutral


Blog/BlogPosts
Using same approach of Taxonomies/Terms.

If locale of Blog and BlogPost are not the same, tries to move BlogPost under a the right Blog translation but if it can't leave things untouched.


Tags
TBD


Container/Containable
TBD

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 10, 2016

Member

@jersiovic @urbanit @Xceno

We intend to do the Taxonomy design meeting tomorrow at 9am PT, i.e. 6pm CET

Member

sebastienros commented Nov 10, 2016

@jersiovic @urbanit @Xceno

We intend to do the Taxonomy design meeting tomorrow at 9am PT, i.e. 6pm CET

@urbanit

This comment has been minimized.

Show comment
Hide comment
@urbanit

urbanit Nov 11, 2016

Contributor

Unfortunately, it will be impossible for me to attend, at least the 1st hour. I will try my best to join later...

Contributor

urbanit commented Nov 11, 2016

Unfortunately, it will be impossible for me to attend, at least the 1st hour. I will try my best to join later...

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 11, 2016

Member

Update on Taxonomies

TERM CONTENT TYPE
Instead of creating a content type for the terms dynamically, we could first create the type, and select it when creating a new Taxonomy.

Q: Can we change the Term Content Type of a taxonomy localization?
No, because when translation an item we don't know yet it's language, hence the term type to create. We need to only be able to create in the same content type as the source taxonomy.

Localization strategies

  • LocalizationPart attached to Taxonomy only
    • Each locale has different hierarchies, terms are not synchronized (terms are not translations of one another)
  • LocalizationPart attached to Term type only (Figure 1)
    • This would allow the Field to display/filter all languages
    • We could have terms without actual localizations
    • We could then have the same options as the Content Item Picker
    • Each localized term has a parent from the Taxonomy's localization
      • We need the parent term to exist in the same culture, or the validation fails
  • LocalizationPart attached to Taxonomy and Term (same as Fig 1)
    • That would work
    • When we localize a term, the new term's taxonomy is the one of the targeted locale
      • We have to create the Taxonomy in a specific locale before being able to create the term in this locale. Validation will be the easiest way.
    • In Fig 1 I can only create C_IT when I have the taxonomy in IT

FIGURE 1

Taxonomy named LETTERS, not localizable
Terms localizable

I can't create B_IT as there is not A_IT
When displaying the taxonomy for FR I can see all terms, in IT I can only see C_IT

  • A_FR
    • B_FR
  • C_FR -> C_IT

Taxonomy Field

  • A. Content item is localizable
    • a. Taxononmy Localizable
      We need to show all the localized taxonomies, with a dropdown list to select one language. A setting can force the user to select terms from the taxonomy of the same language as the current content item.
    • b. Term localizable
      • i. With a setting on the field, we can automatically select the translations of the selected terms (like Content Picker Field)
      • ii. Can validate that the terms in the same language
    • c. Taxonomy & Term localizable
      • i. All from the above two options
  • B. Content item is not localizable
    • a. Do whatever you want, showing all taxonomy languages
Member

sebastienros commented Nov 11, 2016

Update on Taxonomies

TERM CONTENT TYPE
Instead of creating a content type for the terms dynamically, we could first create the type, and select it when creating a new Taxonomy.

Q: Can we change the Term Content Type of a taxonomy localization?
No, because when translation an item we don't know yet it's language, hence the term type to create. We need to only be able to create in the same content type as the source taxonomy.

Localization strategies

  • LocalizationPart attached to Taxonomy only
    • Each locale has different hierarchies, terms are not synchronized (terms are not translations of one another)
  • LocalizationPart attached to Term type only (Figure 1)
    • This would allow the Field to display/filter all languages
    • We could have terms without actual localizations
    • We could then have the same options as the Content Item Picker
    • Each localized term has a parent from the Taxonomy's localization
      • We need the parent term to exist in the same culture, or the validation fails
  • LocalizationPart attached to Taxonomy and Term (same as Fig 1)
    • That would work
    • When we localize a term, the new term's taxonomy is the one of the targeted locale
      • We have to create the Taxonomy in a specific locale before being able to create the term in this locale. Validation will be the easiest way.
    • In Fig 1 I can only create C_IT when I have the taxonomy in IT

FIGURE 1

Taxonomy named LETTERS, not localizable
Terms localizable

I can't create B_IT as there is not A_IT
When displaying the taxonomy for FR I can see all terms, in IT I can only see C_IT

  • A_FR
    • B_FR
  • C_FR -> C_IT

Taxonomy Field

  • A. Content item is localizable
    • a. Taxononmy Localizable
      We need to show all the localized taxonomies, with a dropdown list to select one language. A setting can force the user to select terms from the taxonomy of the same language as the current content item.
    • b. Term localizable
      • i. With a setting on the field, we can automatically select the translations of the selected terms (like Content Picker Field)
      • ii. Can validate that the terms in the same language
    • c. Taxonomy & Term localizable
      • i. All from the above two options
  • B. Content item is not localizable
    • a. Do whatever you want, showing all taxonomy languages
@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 11, 2016

Contributor

I'm just reading now @HermesSbicego-Laser notes and date for the second meeting. I will think about your notes this weekend.
Great effort guys!

Contributor

jersiovic commented Nov 11, 2016

I'm just reading now @HermesSbicego-Laser notes and date for the second meeting. I will think about your notes this weekend.
Great effort guys!

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 14, 2016

Contributor

@sebastienros For taxonomy field I would add some customization through field settings:

  • B. Content item is not localizable
    • a. Do whatever you want, showing all taxonomy languages
      • i. With a setting on the field, we can indicate that translations showed to the user will be only those in the the same language as current culture.
      • ii. With a setting on the field, we can indicate which language has to be used for storing the term selected, no matter which translation the user selected.

Setting ii) helps us to simplify queries over those not localizable content items when we want to filter by term and we don't want to do extra work for filtering by all the possible translations of a term.

Contributor

jersiovic commented Nov 14, 2016

@sebastienros For taxonomy field I would add some customization through field settings:

  • B. Content item is not localizable
    • a. Do whatever you want, showing all taxonomy languages
      • i. With a setting on the field, we can indicate that translations showed to the user will be only those in the the same language as current culture.
      • ii. With a setting on the field, we can indicate which language has to be used for storing the term selected, no matter which translation the user selected.

Setting ii) helps us to simplify queries over those not localizable content items when we want to filter by term and we don't want to do extra work for filtering by all the possible translations of a term.

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 15, 2016

Contributor

@jersiovic, If I understand well you would add two settings in order to manage the situation in which you have a Culture neutral Content Type and a taxonomy field whose source is translatable:

  1. Add a Field setting in order to show the taxonomy in "current culture" as source of a taxonomy field in the Admin.
    Q1: When you say "current Culture" you mean the culture selected within the Admin culture picker or the "default culture" of site (defined in "site settings")?
    Q2: When this setting is true the user cannot choose a different culture?
  2. Add a Field setting in order define the culture of the "Terms Contents" that will be stored in the Taxonomy field:
    Q1: So when the content is saved, it stores the term ids corresponding to the langauge defined in the setting even if another language is choosen? In that case we force to store term ids in a particular language.

Am I right?

Contributor

HermesSbicego-Laser commented Nov 15, 2016

@jersiovic, If I understand well you would add two settings in order to manage the situation in which you have a Culture neutral Content Type and a taxonomy field whose source is translatable:

  1. Add a Field setting in order to show the taxonomy in "current culture" as source of a taxonomy field in the Admin.
    Q1: When you say "current Culture" you mean the culture selected within the Admin culture picker or the "default culture" of site (defined in "site settings")?
    Q2: When this setting is true the user cannot choose a different culture?
  2. Add a Field setting in order define the culture of the "Terms Contents" that will be stored in the Taxonomy field:
    Q1: So when the content is saved, it stores the term ids corresponding to the langauge defined in the setting even if another language is choosen? In that case we force to store term ids in a particular language.

Am I right?

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 15, 2016

Contributor

Yes you are right.

Answer to 1.Q1: Yes when the user is in dashboard the current culture is the one selected though admin culture picker.
Answer to 1.Q2: Yes that is the idea.
Answer to 2.Q1: Yes this is it.

Contributor

jersiovic commented Nov 15, 2016

Yes you are right.

Answer to 1.Q1: Yes when the user is in dashboard the current culture is the one selected though admin culture picker.
Answer to 1.Q2: Yes that is the idea.
Answer to 2.Q1: Yes this is it.

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 15, 2016

Contributor

I don't think we have never used a similar approach but it makes sense for me to have this particular behaviour in order to manage all scenarios, what do you think @sebastienros, @urbanit, @MatteoPiovanelli-Laser?
By the way, we plan to begin working on taxonomies from tomorrow and we will push a PR as soon as possible.

Contributor

HermesSbicego-Laser commented Nov 15, 2016

I don't think we have never used a similar approach but it makes sense for me to have this particular behaviour in order to manage all scenarios, what do you think @sebastienros, @urbanit, @MatteoPiovanelli-Laser?
By the way, we plan to begin working on taxonomies from tomorrow and we will push a PR as soon as possible.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 15, 2016

Contributor

@HermesSbicego-Laser @jersiovic I have concerns about the scenario where the current culture gets changed between edits of a ContentItem that has a TaxonomyField set as per setting 1.

Contributor

MatteoPiovanelli-Laser commented Nov 15, 2016

@HermesSbicego-Laser @jersiovic I have concerns about the scenario where the current culture gets changed between edits of a ContentItem that has a TaxonomyField set as per setting 1.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 16, 2016

Contributor

@sebastienros @jersiovic @urbanit @Xceno @HermesSbicego-Laser
I am starting on the TranslationSetId (because of #7348, #7386 and #7394). I think I will then work on the synchronization for Neutral ContentFields and ContentParts, that would definitely need those issues to be solved for consistency.

For synchronization, we also discussed cloning, so I opened #7409

Contributor

MatteoPiovanelli-Laser commented Nov 16, 2016

@sebastienros @jersiovic @urbanit @Xceno @HermesSbicego-Laser
I am starting on the TranslationSetId (because of #7348, #7386 and #7394). I think I will then work on the synchronization for Neutral ContentFields and ContentParts, that would definitely need those issues to be solved for consistency.

For synchronization, we also discussed cloning, so I opened #7409

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 16, 2016

Contributor

@sebastienros, we started working on Taxonomies Localization (and on Blog/BlogPost also in order to discover problems there) and we are facing so many problems; we branched it from 1.10.x and the missing of the cloning logic create a lot of problems because translated contents are created "anemic" (they lose all context informations); this affects at least all ContentItems which need to be related to a Container and are not Creatable (Terms, BlogPosts, and so on)...
So what I will do is to reintegrate in 1.10.x the work done by @MatteoPiovanelli-Laser on backward compatibility of the cloning feature (#7409) in order to start from a less buggy branch.

IMHO we discovered a really serious bug because from 1.9 what worked into 1.8 stopped working.

Contributor

HermesSbicego-Laser commented Nov 16, 2016

@sebastienros, we started working on Taxonomies Localization (and on Blog/BlogPost also in order to discover problems there) and we are facing so many problems; we branched it from 1.10.x and the missing of the cloning logic create a lot of problems because translated contents are created "anemic" (they lose all context informations); this affects at least all ContentItems which need to be related to a Container and are not Creatable (Terms, BlogPosts, and so on)...
So what I will do is to reintegrate in 1.10.x the work done by @MatteoPiovanelli-Laser on backward compatibility of the cloning feature (#7409) in order to start from a less buggy branch.

IMHO we discovered a really serious bug because from 1.9 what worked into 1.8 stopped working.

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 16, 2016

Member

If the regression you are talking about is the fact that translating an item loses all its data, it's a known issue.
Yes, feel free to continue working on backporting the cloning features, I already commented on Matteo's PR.

Member

sebastienros commented Nov 16, 2016

If the regression you are talking about is the fact that translating an item loses all its data, it's a known issue.
Yes, feel free to continue working on backporting the cloning features, I already commented on Matteo's PR.

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 16, 2016

Contributor

yes, I see. That's fine, I will Update you during tomorrow meeting.

Contributor

HermesSbicego-Laser commented Nov 16, 2016

yes, I see. That's fine, I will Update you during tomorrow meeting.

HermesSbicego-Laser added a commit to LaserSrl/Orchard that referenced this issue Nov 17, 2016

@HermesSbicego-Laser

This comment has been minimized.

Show comment
Hide comment
@HermesSbicego-Laser

HermesSbicego-Laser Nov 17, 2016

Contributor

In order to manage Blog/BlogPost I have a PR ready based on "#7409".

  1. I created a new feature into Orchard.Blogs named Orchard.Blogs.LocalizationExtensions
  2. I used same approach discussed for the relationship between Taxonomies and Terms.
    So, on saving the BlogPost if the locale of Blogand BlogPostare not the same, it tries to move BlogPostunder the right Blogtranslation but if it can't leave things untouched.
  3. I created also a migrationwhich attach LocalizationPartto both Blogand BlogPost.

When #7409 will be ready and tested I will merge and push the PR.

Contributor

HermesSbicego-Laser commented Nov 17, 2016

In order to manage Blog/BlogPost I have a PR ready based on "#7409".

  1. I created a new feature into Orchard.Blogs named Orchard.Blogs.LocalizationExtensions
  2. I used same approach discussed for the relationship between Taxonomies and Terms.
    So, on saving the BlogPost if the locale of Blogand BlogPostare not the same, it tries to move BlogPostunder the right Blogtranslation but if it can't leave things untouched.
  3. I created also a migrationwhich attach LocalizationPartto both Blogand BlogPost.

When #7409 will be ready and tested I will merge and push the PR.

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 17, 2016

Contributor

@HermesSbicego-Laser @jersiovic I have concerns about the scenario where the current culture gets changed between edits of a ContentItem that has a TaxonomyField set as per setting 1.

What kind of concerns? You are worried cause not saved changes will be lost? If it is the problem I think it is not a big problem. Someone editing a non localizable content item usually doesn't need to change the culture cause there is not other translations of the same content item, he only wants to see all the UI and contents in the language he understand.

Contributor

jersiovic commented Nov 17, 2016

@HermesSbicego-Laser @jersiovic I have concerns about the scenario where the current culture gets changed between edits of a ContentItem that has a TaxonomyField set as per setting 1.

What kind of concerns? You are worried cause not saved changes will be lost? If it is the problem I think it is not a big problem. Someone editing a non localizable content item usually doesn't need to change the culture cause there is not other translations of the same content item, he only wants to see all the UI and contents in the language he understand.

sebastienros added a commit that referenced this issue Nov 17, 2016

Implements ContentPicker localization options discussed in #7352 (#7391)
* Squashed commit of the following:

commit bd1e2bf
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Thu Nov 10 12:02:09 2016 +0100

    Added notifications about what the localization methods for ContentPickerField will do or have done.

commit 04eb707
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Wed Nov 9 17:48:59 2016 +0100

    Added the TryTranslate option and its suboptions

commit fad9fa8
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Wed Nov 9 15:31:44 2016 +0100

    Added a new feature to the ContentPicker module.
    So far, it stops saving/publication when the items in the ContentPickerField are the "wrong" culture

commit b90629d
Merge: 578b21b c486355
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Tue Nov 8 09:37:30 2016 +0100

    Merge remote-tracking branch 'remotes/OrchardCMS.Orchard/1.10.x' into Laser/1.10.x

commit 578b21b
Merge: 395976f 3c53ffb
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Nov 4 13:45:51 2016 +0100

    Merge branch 'feature/6688_RequestTokens_Chaintext' into Laser/1.10.x

commit 3c53ffb
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Nov 4 13:43:38 2016 +0100

    - replaced Regex.Replace with String.Trim(char[]) as suggested
    - ran Orchard.Tokens.Tests: 66/66 passed

commit 395976f
Merge: 708ed79 a15557e
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 16:34:50 2016 +0200

    Merge branch 'Laser/1.10.x' of https://github.com/LaserSrl/Orchard into Laser/1.10.x

commit 708ed79
Merge: 5fe0b69 68acf26
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 16:32:52 2016 +0200

    Merge branch '1.10.x' of https://github.com/LaserSrl/Orchard into Laser/1.10.x

commit 5fe0b69
Merge: 0daad70 e3a7059
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 16:32:31 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into Laser/1.10.x

commit e3a7059
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 15:22:48 2016 +0200

    - Addition of an existing png (OrchardLogo.png) as attachment within "Test Smtp Settings" Section, in order to demonstrate functionality of support for attachments in email

commit f095dea
Merge: 7b09747 68acf26
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 12:37:55 2016 +0200

    Merge remote-tracking branch 'remotes/OrchardCMS.Orchard/1.10.x' into feature/6688_RequestTokens_Chaintext

commit a15557e
Merge: 0daad70 ce8a61e
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Thu Oct 27 17:10:53 2016 +0200

    Merge branch 'issues/7346_WidgetsViewQueryString' into Laser/1.10.x

commit 0daad70
Merge: 927d18b 7b09747
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Thu Oct 27 09:07:58 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6688_RequestTokens_Chaintext' into 1.10.x

commit 7b09747
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Thu Oct 27 09:05:17 2016 +0200

    inserted a better explanation on how to use the chains

commit 927d18b
Merge: f8cbc63 17ebdd2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 19:00:44 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6688_RequestTokens_Chaintext' into 1.10.x

commit 17ebdd2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 18:57:48 2016 +0200

    - typo

commit f8cbc63
Merge: 9f42664 1b511b2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 18:53:11 2016 +0200

    Merge branch 'feature/6688_RequestTokens_Chaintext' into 1.10.x

commit 1b511b2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 18:50:35 2016 +0200

    - Implement what described in #6688

    Supported Syntaxes for Request and Form tokens are:
    1. QueryString:(param1) or Form:(param1)
    2. QueryString:param1 or Form:param1
    3. QueryString:(param1).SomeOtherTextToken or Form:(param1).SomeOtherTextToken

    If you want to Chain TextTokens you have to use the 3rd syntax
    the element (here param1) has been surrounded with brackets in order to preserve backward compatibility.

commit ce8a61e
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Wed Oct 26 11:46:24 2016 +0200

    Fixes #7346

commit 9f42664
Merge: 60aa1cc f6cfe32
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:20:57 2016 +0200

    Merge branch '1.10.x' of https://github.com/LaserSrl/Orchard into 1.10.x

commit 60aa1cc
Merge: c1b1c4d 7a16cf5
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:20:28 2016 +0200

    Merge branch '1.10.x' of https://github.com/OrchardCMS/Orchard into 1.10.x

commit c1b1c4d
Merge: bf2201c e50bd60
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:19:54 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6196_SupportForAttachments' into 1.10.x

commit e50bd60
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:18:24 2016 +0200

    - Formatted Code (Rebracer)

commit f6cfe32
Merge: 7a16cf5 bf2201c
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Mon Oct 24 09:24:57 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/1.10.x' into 1.10.x
    Ho fatto pull della 1.10 remota di Orchard

commit bf2201c
Merge: 67af300 580b79c
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 18:40:21 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

    # Conflicts:
    #	src/Orchard.Web/Modules/Orchard.Email/Services/SmtpMessageChannel.cs

commit 580b79c
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:46:08 2016 +0200

    - Added attachments logic

commit 67af300
Merge: d4d4a32 a4c816b
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:56:13 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

commit a4c816b
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:55:38 2016 +0200

    - missing Attachments Key fix

commit d4d4a32
Merge: 297e586 2bb81ee
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:46:40 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

commit 2bb81ee
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:46:08 2016 +0200

    - Added attachments logic

commit 297e586
Merge: 54a1bdf 548b5d7
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 09:39:11 2016 +0200

    Merge branch 'feature/5790_partecipate_in_cache_key_generation' into 1.10.x

commit 548b5d7
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 09:37:07 2016 +0200

    - Method renamed
    - try catch removed

commit 54a1bdf
Merge: b7ee130 794b9b0
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 17:51:29 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/5790_partecipate_in_cache_key_generation' into 1.10.x

commit 794b9b0
Merge: 1dcee8a 350cbbd
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 17:44:35 2016 +0200

    Merge branch 'feature/5790_partecipate_in_cache_key_generation' of https://github.com/LaserSrl/Orchard into feature/5790_partecipate_in_cache_key_generation

commit 1dcee8a
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 16:30:12 2016 +0200

    - typo chaching > caching

    - added EventHandler in order to partecipate in cachekey generation

commit 350cbbd
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 17:40:58 2016 +0200

    - typo chaching > caching

commit b7ee130
Merge: c9e14f9 58e59e2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 16:32:13 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/5790_partecipate_in_cache_key_generation' into 1.10.x

commit 58e59e2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 16:30:12 2016 +0200

    - added EventHandler in order to partecipate in cachekey generation

commit c9e14f9
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Mon Oct 17 12:54:53 2016 +0200

    Modified the OutputCache Module based on the enhancement proposed in Issue 5811,
    by adding a VaryByRequestCookies property to the CacheSettingsPart to enable the generation of the Cache Key based on cookies

* Changed the view as reccomended by @sebastienros in his comments

* Added culture information to the contentpickerfield editor view

* Fixed a bug in the handler (!= instead of ==)

* showing displaytext in warnings and notifications rather than content item's id

* Cleanup. I
ContentPickerFieldLocalizationDriver Editor methods are executed correctly on validation errors, so they load the additional javascript correctly
@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 17, 2016

Contributor

@jersiovic maybe I misunderstood what you proposed. I will try to explain the way I understood things, so you can see what I may have gotten wrong. Please, correct me.

Setting 1 I mentioned was for the case where the ContentType that has the TaxonomyField is not localizable (does not have a LocalizationPart): by enabling setting 1 we are causing the TaxonomyField, when we are editing a ContentItem, to only show, as available for selection, Terms whose culture is the same as the Current Culture.
Say for example I have ITEM-A that is of one such type, my Current Culture is it-IT, and in my "Sports" TaxonomyField I select the Term "Calcio". All is fine.
Now I change my Current Culture to en-US. I open ITEM-A in Edit again. My TaxonmyField "Sports" is still set to "Calcio", that is my Italian term. However, I now cannot select Italian Terms, so if I make any change, I cannot select "Calcio" again, and I am stuck with a different list of terms.

Contributor

MatteoPiovanelli-Laser commented Nov 17, 2016

@jersiovic maybe I misunderstood what you proposed. I will try to explain the way I understood things, so you can see what I may have gotten wrong. Please, correct me.

Setting 1 I mentioned was for the case where the ContentType that has the TaxonomyField is not localizable (does not have a LocalizationPart): by enabling setting 1 we are causing the TaxonomyField, when we are editing a ContentItem, to only show, as available for selection, Terms whose culture is the same as the Current Culture.
Say for example I have ITEM-A that is of one such type, my Current Culture is it-IT, and in my "Sports" TaxonomyField I select the Term "Calcio". All is fine.
Now I change my Current Culture to en-US. I open ITEM-A in Edit again. My TaxonmyField "Sports" is still set to "Calcio", that is my Italian term. However, I now cannot select Italian Terms, so if I make any change, I cannot select "Calcio" again, and I am stuck with a different list of terms.

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 17, 2016

Contributor

@MatteoPiovanelli-Laser Yes you are right.
An alternative could be to show the master term when the translation in current culture is not available.
But IMO this extra work is not worth because is confusing for user and also for the admin of the site to understand what is happening.
The point is the use of Setting 1 has only sense for taxonomies where you plan to have all the terms of your taxonomy translated to all available cultures. If not this settings is not useful and is weird someone is willing to use it. Maybe a tooltip in the setting saying: "Use only with taxonomies with terms translated to all available cultures" will help to avoid misunderstandings.
I think it is better to left it as you describe it: the user can't select the term because it is not on current culture. In that way the user understands that sth goes wrong with translation of that term and admin of the site the same.

Contributor

jersiovic commented Nov 17, 2016

@MatteoPiovanelli-Laser Yes you are right.
An alternative could be to show the master term when the translation in current culture is not available.
But IMO this extra work is not worth because is confusing for user and also for the admin of the site to understand what is happening.
The point is the use of Setting 1 has only sense for taxonomies where you plan to have all the terms of your taxonomy translated to all available cultures. If not this settings is not useful and is weird someone is willing to use it. Maybe a tooltip in the setting saying: "Use only with taxonomies with terms translated to all available cultures" will help to avoid misunderstandings.
I think it is better to left it as you describe it: the user can't select the term because it is not on current culture. In that way the user understands that sth goes wrong with translation of that term and admin of the site the same.

MatteoPiovanelli-Laser added a commit to LaserSrl/Orchard that referenced this issue Nov 18, 2016

Squashed commit of the following:
commit 4299239
Author: Hermes Sbicego <hermes.sbicego@laser-group.com>
Date:   Thu Nov 17 22:02:54 2016 +0100

    Implements what described in #6688 (#7356)

    Fixes #6688

commit 7e859f2
Author: Hannan Azam Khan <hannan.azam@gmail.com>
Date:   Fri Nov 18 01:54:04 2016 +0500

    Default Tag Cache from HttpContext (#7280)

    Fixes #7240

commit 4584da9
Author: Matteo Piovanelli <matteo.piovanelli@laser-group.com>
Date:   Thu Nov 17 21:49:35 2016 +0100

    Content picker localization culture dropdown (#7388)

commit f697fbb
Author: Matteo Piovanelli <matteo.piovanelli@laser-group.com>
Date:   Thu Nov 17 21:47:58 2016 +0100

    Implements ContentPicker localization options discussed in #7352 (#7391)

    * Squashed commit of the following:

    commit bd1e2bf
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Thu Nov 10 12:02:09 2016 +0100

        Added notifications about what the localization methods for ContentPickerField will do or have done.

    commit 04eb707
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Wed Nov 9 17:48:59 2016 +0100

        Added the TryTranslate option and its suboptions

    commit fad9fa8
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Wed Nov 9 15:31:44 2016 +0100

        Added a new feature to the ContentPicker module.
        So far, it stops saving/publication when the items in the ContentPickerField are the "wrong" culture

    commit b90629d
    Merge: 578b21b c486355
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Tue Nov 8 09:37:30 2016 +0100

        Merge remote-tracking branch 'remotes/OrchardCMS.Orchard/1.10.x' into Laser/1.10.x

    commit 578b21b
    Merge: 395976f 3c53ffb
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Nov 4 13:45:51 2016 +0100

        Merge branch 'feature/6688_RequestTokens_Chaintext' into Laser/1.10.x

    commit 3c53ffb
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Nov 4 13:43:38 2016 +0100

        - replaced Regex.Replace with String.Trim(char[]) as suggested
        - ran Orchard.Tokens.Tests: 66/66 passed

    commit 395976f
    Merge: 708ed79 a15557e
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 28 16:34:50 2016 +0200

        Merge branch 'Laser/1.10.x' of https://github.com/LaserSrl/Orchard into Laser/1.10.x

    commit 708ed79
    Merge: 5fe0b69 68acf26
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 28 16:32:52 2016 +0200

        Merge branch '1.10.x' of https://github.com/LaserSrl/Orchard into Laser/1.10.x

    commit 5fe0b69
    Merge: 0daad70 e3a7059
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 28 16:32:31 2016 +0200

        Merge branch 'feature/6196_SupportForAttachments' into Laser/1.10.x

    commit e3a7059
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 28 15:22:48 2016 +0200

        - Addition of an existing png (OrchardLogo.png) as attachment within "Test Smtp Settings" Section, in order to demonstrate functionality of support for attachments in email

    commit f095dea
    Merge: 7b09747 68acf26
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 28 12:37:55 2016 +0200

        Merge remote-tracking branch 'remotes/OrchardCMS.Orchard/1.10.x' into feature/6688_RequestTokens_Chaintext

    commit a15557e
    Merge: 0daad70 ce8a61e
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Thu Oct 27 17:10:53 2016 +0200

        Merge branch 'issues/7346_WidgetsViewQueryString' into Laser/1.10.x

    commit 0daad70
    Merge: 927d18b 7b09747
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Thu Oct 27 09:07:58 2016 +0200

        Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6688_RequestTokens_Chaintext' into 1.10.x

    commit 7b09747
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Thu Oct 27 09:05:17 2016 +0200

        inserted a better explanation on how to use the chains

    commit 927d18b
    Merge: f8cbc63 17ebdd2
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 26 19:00:44 2016 +0200

        Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6688_RequestTokens_Chaintext' into 1.10.x

    commit 17ebdd2
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 26 18:57:48 2016 +0200

        - typo

    commit f8cbc63
    Merge: 9f42664 1b511b2
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 26 18:53:11 2016 +0200

        Merge branch 'feature/6688_RequestTokens_Chaintext' into 1.10.x

    commit 1b511b2
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 26 18:50:35 2016 +0200

        - Implement what described in #6688

        Supported Syntaxes for Request and Form tokens are:
        1. QueryString:(param1) or Form:(param1)
        2. QueryString:param1 or Form:param1
        3. QueryString:(param1).SomeOtherTextToken or Form:(param1).SomeOtherTextToken

        If you want to Chain TextTokens you have to use the 3rd syntax
        the element (here param1) has been surrounded with brackets in order to preserve backward compatibility.

    commit ce8a61e
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Wed Oct 26 11:46:24 2016 +0200

        Fixes #7346

    commit 9f42664
    Merge: 60aa1cc f6cfe32
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Tue Oct 25 09:20:57 2016 +0200

        Merge branch '1.10.x' of https://github.com/LaserSrl/Orchard into 1.10.x

    commit 60aa1cc
    Merge: c1b1c4d 7a16cf5
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Tue Oct 25 09:20:28 2016 +0200

        Merge branch '1.10.x' of https://github.com/OrchardCMS/Orchard into 1.10.x

    commit c1b1c4d
    Merge: bf2201c e50bd60
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Tue Oct 25 09:19:54 2016 +0200

        Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6196_SupportForAttachments' into 1.10.x

    commit e50bd60
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Tue Oct 25 09:18:24 2016 +0200

        - Formatted Code (Rebracer)

    commit f6cfe32
    Merge: 7a16cf5 bf2201c
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Mon Oct 24 09:24:57 2016 +0200

        Merge remote-tracking branch 'remotes/Laser.Orchard/1.10.x' into 1.10.x
        Ho fatto pull della 1.10 remota di Orchard

    commit bf2201c
    Merge: 67af300 580b79c
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 18:40:21 2016 +0200

        Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

        # Conflicts:
        #	src/Orchard.Web/Modules/Orchard.Email/Services/SmtpMessageChannel.cs

    commit 580b79c
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 11:46:08 2016 +0200

        - Added attachments logic

    commit 67af300
    Merge: d4d4a32 a4c816b
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 11:56:13 2016 +0200

        Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

    commit a4c816b
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 11:55:38 2016 +0200

        - missing Attachments Key fix

    commit d4d4a32
    Merge: 297e586 2bb81ee
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 11:46:40 2016 +0200

        Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

    commit 2bb81ee
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 11:46:08 2016 +0200

        - Added attachments logic

    commit 297e586
    Merge: 54a1bdf 548b5d7
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 09:39:11 2016 +0200

        Merge branch 'feature/5790_partecipate_in_cache_key_generation' into 1.10.x

    commit 548b5d7
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Fri Oct 21 09:37:07 2016 +0200

        - Method renamed
        - try catch removed

    commit 54a1bdf
    Merge: b7ee130 794b9b0
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 19 17:51:29 2016 +0200

        Merge remote-tracking branch 'remotes/Laser.Orchard/feature/5790_partecipate_in_cache_key_generation' into 1.10.x

    commit 794b9b0
    Merge: 1dcee8a 350cbbd
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 19 17:44:35 2016 +0200

        Merge branch 'feature/5790_partecipate_in_cache_key_generation' of https://github.com/LaserSrl/Orchard into feature/5790_partecipate_in_cache_key_generation

    commit 1dcee8a
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 19 16:30:12 2016 +0200

        - typo chaching > caching

        - added EventHandler in order to partecipate in cachekey generation

    commit 350cbbd
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 19 17:40:58 2016 +0200

        - typo chaching > caching

    commit b7ee130
    Merge: c9e14f9 58e59e2
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 19 16:32:13 2016 +0200

        Merge remote-tracking branch 'remotes/Laser.Orchard/feature/5790_partecipate_in_cache_key_generation' into 1.10.x

    commit 58e59e2
    Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
    Date:   Wed Oct 19 16:30:12 2016 +0200

        - added EventHandler in order to partecipate in cachekey generation

    commit c9e14f9
    Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
    Date:   Mon Oct 17 12:54:53 2016 +0200

        Modified the OutputCache Module based on the enhancement proposed in Issue 5811,
        by adding a VaryByRequestCookies property to the CacheSettingsPart to enable the generation of the Cache Key based on cookies

    * Changed the view as reccomended by @sebastienros in his comments

    * Added culture information to the contentpickerfield editor view

    * Fixed a bug in the handler (!= instead of ==)

    * showing displaytext in warnings and notifications rather than content item's id

    * Cleanup. I
    ContentPickerFieldLocalizationDriver Editor methods are executed correctly on validation errors, so they load the additional javascript correctly

commit 1254a11
Author: Thierry Fleury <thierry@codinlab.fr>
Date:   Thu Nov 17 21:47:15 2016 +0100

    Sort Taxonomies Terms failed

    Fixes #6795

commit 203fd95
Author: hacko-bede <atanas.simeonov@bedegaming.com>
Date:   Thu Nov 17 22:37:55 2016 +0200

    Delete scheduled task when content is published

    Fixes #6840
@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 21, 2016

Contributor

In #7416 I implemented the LocalizationSetIds we discussed early on.

I am now using that and #7409 to build the synchronization for CultureNeutral Fields and Parts.

Contributor

MatteoPiovanelli-Laser commented Nov 21, 2016

In #7416 I implemented the LocalizationSetIds we discussed early on.

I am now using that and #7409 to build the synchronization for CultureNeutral Fields and Parts.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 21, 2016

Contributor

I actually have a question, because I forget what we meant by this:

  • How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)

    • We need to select the MCI id

@sebastienros @jersiovic @urbanit @HermesSbicego-Laser
I don't remember what we meant by "culture neutral content item".
Isn't that just a ContentItem that does not have a LocalizationPart?
Or are we saying that an item that has a LocalizationPart can be marked as CultureNeutral?
Does that even make sense?
If that is the case, what happens to any localization it may have, or that we may create for it?

Contributor

MatteoPiovanelli-Laser commented Nov 21, 2016

I actually have a question, because I forget what we meant by this:

  • How to select a content neutral content item (from any culture, not culture specific, i.e. the TS id)

    • We need to select the MCI id

@sebastienros @jersiovic @urbanit @HermesSbicego-Laser
I don't remember what we meant by "culture neutral content item".
Isn't that just a ContentItem that does not have a LocalizationPart?
Or are we saying that an item that has a LocalizationPart can be marked as CultureNeutral?
Does that even make sense?
If that is the case, what happens to any localization it may have, or that we may create for it?

@urbanit

This comment has been minimized.

Show comment
Hide comment
@urbanit

urbanit Nov 21, 2016

Contributor

Hi @MatteoPiovanelli-Laser , I think that we mean that we may need to select a specific content item (without take into account if it has localisation info attached or not, and maybe from diffrent culture...) We described the need to choose a specific content item...

Contributor

urbanit commented Nov 21, 2016

Hi @MatteoPiovanelli-Laser , I think that we mean that we may need to select a specific content item (without take into account if it has localisation info attached or not, and maybe from diffrent culture...) We described the need to choose a specific content item...

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 21, 2016

Contributor

@urbanit
That may have jogged my memory, and I think you are right.
So that is not something related to synchronization of parts and fields.

Contributor

MatteoPiovanelli-Laser commented Nov 21, 2016

@urbanit
That may have jogged my memory, and I think you are right.
So that is not something related to synchronization of parts and fields.

@urbanit

This comment has been minimized.

Show comment
Hide comment
@urbanit

urbanit Nov 21, 2016

Contributor

I think it is more of translating/cloning issue than of synchronization.

Contributor

urbanit commented Nov 21, 2016

I think it is more of translating/cloning issue than of synchronization.

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Nov 21, 2016

Contributor

@MatteoPiovanelli-Laser @urbanit It was related with what I wanted in an scenario where we have a non localizable content item with a content picker field pointing to localizable contents. I wanted to store in the field picker the Translation Set Id but not any concrete content item id of the translations available. The purpose was that when the pantent content item is rendered or edited the content item picker field shows the child content item with the stored Translation Set Id and same culture you are using to render the parent content item.

But if you implement Setting 1 and Setting 2 we talked previously in this thread then I don't need this.

Contributor

jersiovic commented Nov 21, 2016

@MatteoPiovanelli-Laser @urbanit It was related with what I wanted in an scenario where we have a non localizable content item with a content picker field pointing to localizable contents. I wanted to store in the field picker the Translation Set Id but not any concrete content item id of the translations available. The purpose was that when the pantent content item is rendered or edited the content item picker field shows the child content item with the stored Translation Set Id and same culture you are using to render the parent content item.

But if you implement Setting 1 and Setting 2 we talked previously in this thread then I don't need this.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 21, 2016

Contributor

@urbanit @jersiovic Ok, I understand now. Thanks.

Contributor

MatteoPiovanelli-Laser commented Nov 21, 2016

@urbanit @jersiovic Ok, I understand now. Thanks.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 22, 2016

Contributor

Hello,

I have the synchronization working (on my machine) on a branch based on the PRs I did for LocalizationSets and Cloning. (branch: https://github.com/LaserSrl/Orchard/tree/CultureNeutralPartsAndFields)

I had to make a few changes that should not break anything. I had to add string properties to CloneContentContext, ExportContentContext and ImportContentContext to avoid synchronizing fields that should not be synchronized. For the ExportContentContextand ImportContentContextclasses, I put that property in a base class they now (in my branch) inherit from, because of the way the ContentFieldDriver works (see the Process methods).

In light what I did for the cloning fallback, I don't feel that adding a parameter to CloneContentContext to mark the fact that we are using it for a translation is enough. I would directly add Translating/Translated methods, falling back on Cloning/Cloned if not implemented, with their own TranslateContentContext. I see how that would be a mess, at least for retrocompatibility, in terms of ContentHandlers (I think I would have to do an interface like ITranslatingContentHandler, inheriting from IContentHandler, and then implement from there similarly to what is in the cloning pr for IContentCloningPartDriver) and drivers (IContentTranslatingPartDriver and so on...), but it would also allow really neat stuff.
TL;DR: I would have a Translating driver method, defaulting to Cloning, that in turn defaults to Export/Import.

@sebastienros
Do you think we'll be able, at today's meeting, to give a quick look at LocalizationSetIds and Cloning?

Contributor

MatteoPiovanelli-Laser commented Nov 22, 2016

Hello,

I have the synchronization working (on my machine) on a branch based on the PRs I did for LocalizationSets and Cloning. (branch: https://github.com/LaserSrl/Orchard/tree/CultureNeutralPartsAndFields)

I had to make a few changes that should not break anything. I had to add string properties to CloneContentContext, ExportContentContext and ImportContentContext to avoid synchronizing fields that should not be synchronized. For the ExportContentContextand ImportContentContextclasses, I put that property in a base class they now (in my branch) inherit from, because of the way the ContentFieldDriver works (see the Process methods).

In light what I did for the cloning fallback, I don't feel that adding a parameter to CloneContentContext to mark the fact that we are using it for a translation is enough. I would directly add Translating/Translated methods, falling back on Cloning/Cloned if not implemented, with their own TranslateContentContext. I see how that would be a mess, at least for retrocompatibility, in terms of ContentHandlers (I think I would have to do an interface like ITranslatingContentHandler, inheriting from IContentHandler, and then implement from there similarly to what is in the cloning pr for IContentCloningPartDriver) and drivers (IContentTranslatingPartDriver and so on...), but it would also allow really neat stuff.
TL;DR: I would have a Translating driver method, defaulting to Cloning, that in turn defaults to Export/Import.

@sebastienros
Do you think we'll be able, at today's meeting, to give a quick look at LocalizationSetIds and Cloning?

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 22, 2016

Member

Yes, please demo it.

On Nov 22, 2016 7:19 AM, "Matteo Piovanelli" notifications@github.com
wrote:

Hello,

I have the synchronization working (on my machine) on a branch based on
the PRs I did for LocalizationSets and Cloning. (branch:
https://github.com/LaserSrl/Orchard/tree/CultureNeutralPartsAndFields)

I had to make a few changes that should not break anything. I had to
add string properties to CloneContentContext, ExportContentContext and
ImportContentContext to avoid synchronizing fields that should not be
synchronized. For the ExportContentContextand ImportContentContextclasses,
I put that property in a base class they now (in my branch) inherit from,
because of the way the ContentFieldDriver works (see the Process methods).

In light what I did for the cloning fallback, I don't feel that adding a
parameter to CloneContentContext to mark the fact that we are using it
for a translation is enough. I would directly add Translating/Translated
methods, falling back on Cloning/Cloned if not implemented, with their own
TranslateContentContext. I see how that would be a mess, at least for
retrocompatibility, in terms of ContentHandlers (I think I would have to do
an interface like ITranslatingContentHandler, inheriting from
IContentHandler, and then implement from there similarly to what is in
the cloning pr for IContentCloningPartDriver) and drivers (
IContentTranslatingPartDriver and so on...), but it would also allow
really neat stuff.
TL;DR: I would have a Translating driver method, defaulting to Cloning,
that in turn defaults to Export/Import.

@sebastienros https://github.com/sebastienros
Do you think we'll be able, at today's meeting, to give a quick look at
LocalizationSetIds and Cloning?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7352 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHJ7RFhsW2z-arkgsKf56we4_ZoaD6Aks5rAwf0gaJpZM4KgBIS
.

Member

sebastienros commented Nov 22, 2016

Yes, please demo it.

On Nov 22, 2016 7:19 AM, "Matteo Piovanelli" notifications@github.com
wrote:

Hello,

I have the synchronization working (on my machine) on a branch based on
the PRs I did for LocalizationSets and Cloning. (branch:
https://github.com/LaserSrl/Orchard/tree/CultureNeutralPartsAndFields)

I had to make a few changes that should not break anything. I had to
add string properties to CloneContentContext, ExportContentContext and
ImportContentContext to avoid synchronizing fields that should not be
synchronized. For the ExportContentContextand ImportContentContextclasses,
I put that property in a base class they now (in my branch) inherit from,
because of the way the ContentFieldDriver works (see the Process methods).

In light what I did for the cloning fallback, I don't feel that adding a
parameter to CloneContentContext to mark the fact that we are using it
for a translation is enough. I would directly add Translating/Translated
methods, falling back on Cloning/Cloned if not implemented, with their own
TranslateContentContext. I see how that would be a mess, at least for
retrocompatibility, in terms of ContentHandlers (I think I would have to do
an interface like ITranslatingContentHandler, inheriting from
IContentHandler, and then implement from there similarly to what is in
the cloning pr for IContentCloningPartDriver) and drivers (
IContentTranslatingPartDriver and so on...), but it would also allow
really neat stuff.
TL;DR: I would have a Translating driver method, defaulting to Cloning,
that in turn defaults to Export/Import.

@sebastienros https://github.com/sebastienros
Do you think we'll be able, at today's meeting, to give a quick look at
LocalizationSetIds and Cloning?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7352 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHJ7RFhsW2z-arkgsKf56we4_ZoaD6Aks5rAwf0gaJpZM4KgBIS
.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Nov 22, 2016

Contributor

@sebastienros
Would it be ok if I showed the branch where I have the synchronization?
If I have to demo LocalizationSetIds and Cloning separately, it would take a while on my machine to rebuild the different branches and set things up again.
Or would you like me to demo the synchronization as well?

Contributor

MatteoPiovanelli-Laser commented Nov 22, 2016

@sebastienros
Would it be ok if I showed the branch where I have the synchronization?
If I have to demo LocalizationSetIds and Cloning separately, it would take a while on my machine to rebuild the different branches and set things up again.
Or would you like me to demo the synchronization as well?

@sebastienros

This comment has been minimized.

Show comment
Hide comment
@sebastienros

sebastienros Nov 22, 2016

Member

I don't understand what branches you are talking about, I'll just trust your judgement.

Member

sebastienros commented Nov 22, 2016

I don't understand what branches you are talking about, I'll just trust your judgement.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Jan 11, 2017

Contributor

Hello.

After a busy stretch (and some vacation) we are back to work on localizations.

I wil try to recap where we stand and our next steps. Please, pitch in with comments.

The things that were left hanging from December, I think, are:

Localization Sets
See #7386, #7394, #7348, #7416
There are issues in the way the MasterContentItem is handled in the Localization module (in 1.10.x). In the discussions related to localization, it was proposed to have an Id describing what we called a Localization Set. This is implemented in #7416, by adding a LocalizationSetId property to the LocalizationPartRecord, and handling the logic on that.
However, in that commit we introduced an additional service (ILocalizationSetService) rather than correct the behaviour of the existing ILocalizationService. This was done for retrocompatibility: the LocalizationService has been in its (possibly bugged, see #7394) state for a long time, and I would expect that people using it have their own workarounds in place, so "simply" fixing that may break logic depending on the service.
@HermesSbicego-Laser discussed this offline with @sebastienros, and it is my understanding that this solution is troublesome in that it introduces a duplication of some functionality between the ILocalizationService (using MasterContentItemId) and the ILocalizationSetService (using LocalizationSetId). A proposed solution to this is that we can fix the behaviours revolving around the MasterContentItemId in the LocalizationService: since this would potentially be a breaking change, we would push this to the dev branch, to be reintegrated later.
*How does this sound? Should we make these changes to the LocalizationService and push a PR targeted to the dev branch (and maybe to 1.11)? *

Cloning
See #7409
The thread for that Pull Request has a long discussion on this. Briefly, I took the cloning feature that @TFleury had implemented from the dev branch, and worked on making it retrocompatible with 1.10.x so that it could be used in localizations.
The result of that is the introduction of new interfaces for drivers, in order to avoid modifying the pre-existing ones, as well as new abstract driver implementations. Using those, I introduced a fallback behaviour in the driver coordinators, so that if a part's (or field's) drivers do not implement the cloning interface, the cloning is still performed using Export/Import, as used to be the norm.
The implementation was initially done using reflection, but there is a version that does not use that (see https://github.com/LaserSrl/Orchard/tree/CloningFeatureWithFallbackNoReflection) that I can push to the PR.
I can see some issues in bringing the pr to dev, because it may break the cloning that was done there in the PR by @TFleury (even though I don't think it is actually merged in dev right now). The thing is, if the cloning/cloned methods are in the IContentPartDriver, rather than being declared in a separate interface, I am not sure how to do the fallback without using reflection.
Assuming for a moment we removed all the reflection, would this be ok to be merged in 1.10.x? Personally, I like the approach of having additional interfaces and abstract classes to add to the drivers, because it looks easy to expand upon down the line without breaking anything.

Culture Neutral Synchronization
As was discussed in an earlier post, I have an implementation for this behaviour based off Cloning and Localization Sets. Once we finalize a decision on those, I can quickly put together a PR, and then we can discuss this in more detail.

Translating
The reason we discussed and worked on the cloning was because we plan to use it to prepopulate some parts/fields when doing translations, and also to synchronize parts/fields across a Localization Set.
The idea is to modify the CloneContentContext by adding properties to it to mark a Cloning "event" as a translation and behave accordingly. This is doable. However, in light of what I did for the synchronization of CultureNeutral Parts and Fields and to remove reflection from the cloning fallbacks, I do not think this is enough. Basically, my idea is that Translating should default to Cloning, that in turns falls back on Export/Import. If we use a condition in Cloning to do Translating, than we may have a case where:

  • for a part, I want a specific behaviour when Translating (e.g.: I google-translate the Title in TitlePart), but I want to leave things to their old Export/Import default when Cloning. So I implement a Cloning method in that part's driver to check for the condition based on the property of CloneContentContext and do stuff.
  • When I make a new Translation, everything is fine.
  • When I try to clone the part, the coordinator "sees" that its driver implement Cloning, so it does not run through the fallback.

My idea then is then to create an IContentTranslatingPartDriver , abstract ContentTranslatingPartDriver , and probably a TranslatingPartDriverCoordinator (which would require, I think, to have an IContentTranslatingHandler and a TranslatingHandlerBase) (similarly for fields), that allow Tranlsating/Translated methods, in a similar way to what was done above for Cloning. The main difference would be that I'd rather implement these classes and interfaces in the Localization module rather than in the Framework project. Note that the IContentTranslatingPartDriver would not inherit from the IContentCloningPartDriver, otherwise we would have the same issue for the fallback that I mentioned above.
How does this approach sound? I am not sure I was really able to get what I mean across, so I'd like questions and doubts about this. Even more, I'd like someone to point me to any issue I may not be seeing here.

Cheers,
Matteo

Contributor

MatteoPiovanelli-Laser commented Jan 11, 2017

Hello.

After a busy stretch (and some vacation) we are back to work on localizations.

I wil try to recap where we stand and our next steps. Please, pitch in with comments.

The things that were left hanging from December, I think, are:

Localization Sets
See #7386, #7394, #7348, #7416
There are issues in the way the MasterContentItem is handled in the Localization module (in 1.10.x). In the discussions related to localization, it was proposed to have an Id describing what we called a Localization Set. This is implemented in #7416, by adding a LocalizationSetId property to the LocalizationPartRecord, and handling the logic on that.
However, in that commit we introduced an additional service (ILocalizationSetService) rather than correct the behaviour of the existing ILocalizationService. This was done for retrocompatibility: the LocalizationService has been in its (possibly bugged, see #7394) state for a long time, and I would expect that people using it have their own workarounds in place, so "simply" fixing that may break logic depending on the service.
@HermesSbicego-Laser discussed this offline with @sebastienros, and it is my understanding that this solution is troublesome in that it introduces a duplication of some functionality between the ILocalizationService (using MasterContentItemId) and the ILocalizationSetService (using LocalizationSetId). A proposed solution to this is that we can fix the behaviours revolving around the MasterContentItemId in the LocalizationService: since this would potentially be a breaking change, we would push this to the dev branch, to be reintegrated later.
*How does this sound? Should we make these changes to the LocalizationService and push a PR targeted to the dev branch (and maybe to 1.11)? *

Cloning
See #7409
The thread for that Pull Request has a long discussion on this. Briefly, I took the cloning feature that @TFleury had implemented from the dev branch, and worked on making it retrocompatible with 1.10.x so that it could be used in localizations.
The result of that is the introduction of new interfaces for drivers, in order to avoid modifying the pre-existing ones, as well as new abstract driver implementations. Using those, I introduced a fallback behaviour in the driver coordinators, so that if a part's (or field's) drivers do not implement the cloning interface, the cloning is still performed using Export/Import, as used to be the norm.
The implementation was initially done using reflection, but there is a version that does not use that (see https://github.com/LaserSrl/Orchard/tree/CloningFeatureWithFallbackNoReflection) that I can push to the PR.
I can see some issues in bringing the pr to dev, because it may break the cloning that was done there in the PR by @TFleury (even though I don't think it is actually merged in dev right now). The thing is, if the cloning/cloned methods are in the IContentPartDriver, rather than being declared in a separate interface, I am not sure how to do the fallback without using reflection.
Assuming for a moment we removed all the reflection, would this be ok to be merged in 1.10.x? Personally, I like the approach of having additional interfaces and abstract classes to add to the drivers, because it looks easy to expand upon down the line without breaking anything.

Culture Neutral Synchronization
As was discussed in an earlier post, I have an implementation for this behaviour based off Cloning and Localization Sets. Once we finalize a decision on those, I can quickly put together a PR, and then we can discuss this in more detail.

Translating
The reason we discussed and worked on the cloning was because we plan to use it to prepopulate some parts/fields when doing translations, and also to synchronize parts/fields across a Localization Set.
The idea is to modify the CloneContentContext by adding properties to it to mark a Cloning "event" as a translation and behave accordingly. This is doable. However, in light of what I did for the synchronization of CultureNeutral Parts and Fields and to remove reflection from the cloning fallbacks, I do not think this is enough. Basically, my idea is that Translating should default to Cloning, that in turns falls back on Export/Import. If we use a condition in Cloning to do Translating, than we may have a case where:

  • for a part, I want a specific behaviour when Translating (e.g.: I google-translate the Title in TitlePart), but I want to leave things to their old Export/Import default when Cloning. So I implement a Cloning method in that part's driver to check for the condition based on the property of CloneContentContext and do stuff.
  • When I make a new Translation, everything is fine.
  • When I try to clone the part, the coordinator "sees" that its driver implement Cloning, so it does not run through the fallback.

My idea then is then to create an IContentTranslatingPartDriver , abstract ContentTranslatingPartDriver , and probably a TranslatingPartDriverCoordinator (which would require, I think, to have an IContentTranslatingHandler and a TranslatingHandlerBase) (similarly for fields), that allow Tranlsating/Translated methods, in a similar way to what was done above for Cloning. The main difference would be that I'd rather implement these classes and interfaces in the Localization module rather than in the Framework project. Note that the IContentTranslatingPartDriver would not inherit from the IContentCloningPartDriver, otherwise we would have the same issue for the fallback that I mentioned above.
How does this approach sound? I am not sure I was really able to get what I mean across, so I'd like questions and doubts about this. Even more, I'd like someone to point me to any issue I may not be seeing here.

Cheers,
Matteo

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Jan 11, 2017

Contributor

I'll just try to explain what I meant above when I attempted to describe the approach I would follow for the Translating/Translated. I will talk about Parts, but the same stands for Fields.

image
Here I just put the stuff that is in the cloning branch. The changes all happened in Orchard.Framework (besides later adding the Cloning implementations to drivers in different modules)

image
Here is, off the top of my head, what I would be adding in order to implement Translating/Translated, except of course a TranslatingContentContext class inheriting from ContentContextBase.

I hope this helps a bit to clarify this. Please, comment. Note however that I first need to settle on the Cloning aspects mentioned above.

Cheers,
Matteo

Contributor

MatteoPiovanelli-Laser commented Jan 11, 2017

I'll just try to explain what I meant above when I attempted to describe the approach I would follow for the Translating/Translated. I will talk about Parts, but the same stands for Fields.

image
Here I just put the stuff that is in the cloning branch. The changes all happened in Orchard.Framework (besides later adding the Cloning implementations to drivers in different modules)

image
Here is, off the top of my head, what I would be adding in order to implement Translating/Translated, except of course a TranslatingContentContext class inheriting from ContentContextBase.

I hope this helps a bit to clarify this. Please, comment. Note however that I first need to settle on the Cloning aspects mentioned above.

Cheers,
Matteo

@BenedekFarkas

This comment has been minimized.

Show comment
Hide comment
@BenedekFarkas

BenedekFarkas Feb 16, 2017

Member

Hey everyone, awesome stuff here! One quick remark (and I'd be happy to take part in the upcoming design process to continue this work): AutoroutePart is kind of special in a way that TitlePart affects its behaviour. If you enable the setting in AutoroutePart to regenerate it every time you change the Title, then enabling sync on TitlePart is going to mean that the AutoroutePart of the translated versions are also updated, so you'll end up with the same routes suffixed with numbers (though I'm not 100% sure about this as this automated process might be a bit different than doing this on the UI). It might not be a problem, actually, just something we may want/try to avoid.

Member

BenedekFarkas commented Feb 16, 2017

Hey everyone, awesome stuff here! One quick remark (and I'd be happy to take part in the upcoming design process to continue this work): AutoroutePart is kind of special in a way that TitlePart affects its behaviour. If you enable the setting in AutoroutePart to regenerate it every time you change the Title, then enabling sync on TitlePart is going to mean that the AutoroutePart of the translated versions are also updated, so you'll end up with the same routes suffixed with numbers (though I'm not 100% sure about this as this automated process might be a bit different than doing this on the UI). It might not be a problem, actually, just something we may want/try to avoid.

toannguyen241994 added a commit to toannguyen241994/Orchard that referenced this issue Feb 21, 2017

update my fork repository (#1)
* Removed incorrect comments in Gulpfile.js.

* Fixing that with multiple TinyMCE editors on a page multiple toolbars also appeared, see #7022

* Readme: Simplifying the "Project Status" section

* [Fixes #7034] Don't cache pages when status code is changed in the view

* Fixed the output caching of non 200 responses when errors are thrown in views

* Added debug message to output cache when the response isn't cached due to a non 200 status code.

* [Fixes #7003] Fixing NRE

* Fixing that the debug log was created even in Release mode

* Use ISO 8601 format for date times

Fixes #6973

* Identity support to menu create command switch

* Admin, content list, fixed lowercase display and CSS class of bulk labels

* Fixing typos.

Fixes #6902

* Sanitize username in activity

* fix typo of occured for logging messages and notification (#7083)

* Allowing adding classes through ShapeTableBuilder.Describe

Small change to Content.Summary.cshtml to allow module developers to add classes to Content.Summary.cshtml via ShapeTableBuilder.Describe.

Fixes #7089

* Pass the right display type to the widget element. (#7074)

* [Fixes #6812] Add shape attributes to "CreateElementTagBuilder"

* [Fixes #7043] Displaying Multiple Editors from a Custom Part

* [Fixes #7104] - Widget Element Title Encoding Fix

* [Fixes #7119] Path Comparison Case Sensitivity

* [Fixes #7121] Fix incorrect documentation url

* Preserve returnUrl value in Content-User.Edit.cshtml

Fixes #7141 #3447

* Labels hidden when datetime field added (#7146)

Fixes #7144

* Labels hidden when datetime field added (#7146)

Fixes #7144

* Fix incorrect title on edit page

Fixes #7142

* Fix incorrect title on edit page

Fixes #7142

* [Fixes #7129] Boolean.cshtml doesn't have * required support in view (#7133)

* [Fixes #7125] tokenized css class left behind (#7127)

* Allow custom date format when displaying published state

Wen overriding the Parts.Common.Metadata.cshtml in a theme, this will allow for changing the date format used to display the date.

* [Fixes #7132] Orchard.Fields - Inconsistent use of mandatory / required (#7134)

* [Fixes #5708] Orchard.Fields - Inconsistent use of mandatory / required

* finish off updating messages + tests

* fix broken test

* Fixed ContentFieldHarvester when NULL Content

The content field harvester throws an error when the LayoutEditor is rendered without having a content item as the context (BluePrints, for example). The previous code would fall back to simply enumerating all fields of all parts to make available all content fields as elements. However, the content field elements can't render these fields without having a proper content item as context, so it would fail with an exception.

There are scenarios where one might still want to be able to add content field elements on the canvas even when there is no current content item (to create template layouts for example). But to support this, we need to figure out what we want to render if we can;t actually render the content field at design time. Perhaps a simplified representation would suffice in this scenario. To be discussed. Removing the broken feature for now.

* [Fixes #7153] Typo .buton:active in several css files (#7154)

* [Fixes #7153] Typo .buton:active in several css files

[Fixes #7153] Typo .buton:active in several css files

* [Fixes #7153] Typo .buton:active in several css files

[Fixes #7153] Typo .buton:active in several css files

* [Fixes #7153] Typo .buton:active in several css files

[Fixes #7153] Typo .buton:active in several css files

* [Fixes #7153] Typo .buton:active in several css files

[Fixes #7153] Typo .buton:active in several css files

* Added CodeRush for Roslyn settings folder to .gitignore.

* [Fixes #7151] Orchard.Core - Use CDN setting ui not correct (#7152)

[Fixes #7151] Orchard.Core - Use CDN setting ui not correct

* Fields display as "&amp;" instead of "&" in validation error msgs (#7156)

Fixes #7111

* Wrapped owin middleware config (#7161)

This wraps owin middle ware configuration within a work context scope.

Fixes #6991

* Fixes #7120 Hidden Field in Dynamic Forms causes crash (#7123)

Fixes #7120 - If a Hidden Field is added to a DynamicForm without a Value set then it will crash the front end because of a null value.

* Customize blog recipe (#7166)

Fixes #7115

* [Fixes #7131] Orchard.ContentTypes - Add / Edit Field Issues (#7150)

* [Fixes #7192] Orchard.Tags - Manage Tags Admin Page Not Alpha Sorted (#7198)

* line wrap css and bind title attr

Fixes #7208

* Add Orchard.Tags.TagsCloud "no data" message

Fixes #7170

* Orchard.Blogs - Hide Parts_Common_Metadata on blog

Fixes #7171

* [Fixes 7246] Added null checks for version ids

Fixes #7246

* feature - add front end toggling of shape tracing

Fixes #7162

* Blog Recent Posts, Archives, Tag Cloud "no data" msgs

Fixes #7168, Fixes #7169, Fixes #7170

* Fixed an issue with incorrect log message at Indexing module

* Fixed incorrect log message in Indexing module
* Fixed an issue with incorrect log message at Indexing module
* Fixed identation

Fixes #7225

* Orchard.MultiTenancy - Mismatched ConnectionString UI between add/edit

Fixes #7301

* [Fixes #4723] Orchard.Core.Contents - Verify type exists on create content

Fixes #4723, #6769

* Fixed an issue with layout element lookup. (#7305)

Fixes #7304

* [Fixes #6704] Regular Expression for Validating TextField Element (#6705)

Fixes #6704

* [Fixes #5960] LinkEntry needs Sizes Attribute (#7303)

Fixes #5960

* [Fixes #6494] SSL missing settings banner showing on frontend (#7302)

Fixes #6494

* [Fixes #7294] Orchard.Core - Improve wording of Notifier in Content Management admin (#7298)

Fixes #7294

* [Fixes #7299] Update defaults for rebracer.xml (#7300)

Fixes #7299

* [Fixes #7255] Cached items are not evicted on Remove and Destroy (#7281)

Fixes #7255

* [Fixes 6759] Replace Media Item: Replacing an Image/OEmbed with new one (#7160)

Fixes #6759

* [Fixes #7155] Orchard.Framework - GroupInfo generates routes with spaces (#7275)

Fixes #7155

* [Fixes #7318] Orchard.DesignerTools - Setting Id not needed anymore (#7319)

Fixes #7318

* Fixing SQL exception during automatic migrations in PostgreSql

Fixes #6783
Fixes #7323

* [Fixes #5811] Adding a VaryByRequestCookies property to the CacheSettingsPart

Fixes #5811

* [Fixes #7326] Orchard.Widgets - Fix typo in logger (#7327)

* [Fixes #7071] Orchard.Users - Users last login time is not correct (#7325)

Fixes #7071

* [Fixes #7251, Fixes #1659] Orchard.Setup - Blog recipe doesn't create widgets correctly (#7324)

Fixes #7251, Fixes #1659

* [Fixes #7258] Orchard.Core - Tabbed groupby breaks priority (#7321)

Fixes #7258

* Orchard.Roles GetRoles should defer execution (#7320)

Fixes #7278

* [Fixes #7258] Orchard.Core - Tabbed groupby breaks priority (#7336)

Fixes #7258

* Fixed wording of "vary by cookies" option in admin UI.

* Adding missing import/export for UserPart.LastPasswordChangeUtc

* Fixing that for existing users LastPasswordChangeUtc being null caused errors

* Fixing that DateTime.MinValue as default value for LastPasswordChangeUtc causes exception during setup

* [Fixes #7339] Orchard.Widgets - Refactor #7251 (#7342)

Fixes #7339

* [Fixes #7346] Allowing cultures and layers to be selected in Widgets

Fixes #7346

* Update Module.txt (#6945)

* [Feature #5790] Adding cache key generation extensibility (#7334)

* Allow the initial value of some fields to be tokenized (#6613)

Fixes #6613 
Fixes #6237

* Fix Event Bus for null exception (#7360)

EventsInterceptor fails when it tries to locate a generic method on an implementation with a return type. A null check has been added to avoid the exception.

Fixes #4718 
Dixes #4584

* Adding the ability to select whether a Template (content item) will be rendered on the frontend, admin, or both. Fixes #5579.

* Adding import/export for the RenderingMode property of ShapePart

* Changed Audit Trail trimming task to delete all records in one batch, rather than iterating through the table records (#7361)

* LocalizationStreamParser should not fail on faulty PO files

Closes #7387

* Using Invoke helper in Clone() (#7400)

* Delete scheduled task when content is published

Fixes #6840

* Sort Taxonomies Terms failed

Fixes #6795

* Implements ContentPicker localization options discussed in #7352 (#7391)

* Squashed commit of the following:

commit bd1e2bf
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Thu Nov 10 12:02:09 2016 +0100

    Added notifications about what the localization methods for ContentPickerField will do or have done.

commit 04eb707
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Wed Nov 9 17:48:59 2016 +0100

    Added the TryTranslate option and its suboptions

commit fad9fa8
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Wed Nov 9 15:31:44 2016 +0100

    Added a new feature to the ContentPicker module.
    So far, it stops saving/publication when the items in the ContentPickerField are the "wrong" culture

commit b90629d
Merge: 578b21b c486355
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Tue Nov 8 09:37:30 2016 +0100

    Merge remote-tracking branch 'remotes/OrchardCMS.Orchard/1.10.x' into Laser/1.10.x

commit 578b21b
Merge: 395976f 3c53ffb
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Nov 4 13:45:51 2016 +0100

    Merge branch 'feature/6688_RequestTokens_Chaintext' into Laser/1.10.x

commit 3c53ffb
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Nov 4 13:43:38 2016 +0100

    - replaced Regex.Replace with String.Trim(char[]) as suggested
    - ran Orchard.Tokens.Tests: 66/66 passed

commit 395976f
Merge: 708ed79 a15557e
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 16:34:50 2016 +0200

    Merge branch 'Laser/1.10.x' of https://github.com/LaserSrl/Orchard into Laser/1.10.x

commit 708ed79
Merge: 5fe0b69 68acf26
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 16:32:52 2016 +0200

    Merge branch '1.10.x' of https://github.com/LaserSrl/Orchard into Laser/1.10.x

commit 5fe0b69
Merge: 0daad70 e3a7059
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 16:32:31 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into Laser/1.10.x

commit e3a7059
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 15:22:48 2016 +0200

    - Addition of an existing png (OrchardLogo.png) as attachment within "Test Smtp Settings" Section, in order to demonstrate functionality of support for attachments in email

commit f095dea
Merge: 7b09747 68acf26
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 28 12:37:55 2016 +0200

    Merge remote-tracking branch 'remotes/OrchardCMS.Orchard/1.10.x' into feature/6688_RequestTokens_Chaintext

commit a15557e
Merge: 0daad70 ce8a61e
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Thu Oct 27 17:10:53 2016 +0200

    Merge branch 'issues/7346_WidgetsViewQueryString' into Laser/1.10.x

commit 0daad70
Merge: 927d18b 7b09747
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Thu Oct 27 09:07:58 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6688_RequestTokens_Chaintext' into 1.10.x

commit 7b09747
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Thu Oct 27 09:05:17 2016 +0200

    inserted a better explanation on how to use the chains

commit 927d18b
Merge: f8cbc63 17ebdd2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 19:00:44 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6688_RequestTokens_Chaintext' into 1.10.x

commit 17ebdd2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 18:57:48 2016 +0200

    - typo

commit f8cbc63
Merge: 9f42664 1b511b2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 18:53:11 2016 +0200

    Merge branch 'feature/6688_RequestTokens_Chaintext' into 1.10.x

commit 1b511b2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 26 18:50:35 2016 +0200

    - Implement what described in #6688

    Supported Syntaxes for Request and Form tokens are:
    1. QueryString:(param1) or Form:(param1)
    2. QueryString:param1 or Form:param1
    3. QueryString:(param1).SomeOtherTextToken or Form:(param1).SomeOtherTextToken

    If you want to Chain TextTokens you have to use the 3rd syntax
    the element (here param1) has been surrounded with brackets in order to preserve backward compatibility.

commit ce8a61e
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Wed Oct 26 11:46:24 2016 +0200

    Fixes #7346

commit 9f42664
Merge: 60aa1cc f6cfe32
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:20:57 2016 +0200

    Merge branch '1.10.x' of https://github.com/LaserSrl/Orchard into 1.10.x

commit 60aa1cc
Merge: c1b1c4d 7a16cf5
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:20:28 2016 +0200

    Merge branch '1.10.x' of https://github.com/OrchardCMS/Orchard into 1.10.x

commit c1b1c4d
Merge: bf2201c e50bd60
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:19:54 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/6196_SupportForAttachments' into 1.10.x

commit e50bd60
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Tue Oct 25 09:18:24 2016 +0200

    - Formatted Code (Rebracer)

commit f6cfe32
Merge: 7a16cf5 bf2201c
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Mon Oct 24 09:24:57 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/1.10.x' into 1.10.x
    Ho fatto pull della 1.10 remota di Orchard

commit bf2201c
Merge: 67af300 580b79c
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 18:40:21 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

    # Conflicts:
    #	src/Orchard.Web/Modules/Orchard.Email/Services/SmtpMessageChannel.cs

commit 580b79c
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:46:08 2016 +0200

    - Added attachments logic

commit 67af300
Merge: d4d4a32 a4c816b
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:56:13 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

commit a4c816b
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:55:38 2016 +0200

    - missing Attachments Key fix

commit d4d4a32
Merge: 297e586 2bb81ee
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:46:40 2016 +0200

    Merge branch 'feature/6196_SupportForAttachments' into 1.10.x

commit 2bb81ee
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 11:46:08 2016 +0200

    - Added attachments logic

commit 297e586
Merge: 54a1bdf 548b5d7
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 09:39:11 2016 +0200

    Merge branch 'feature/5790_partecipate_in_cache_key_generation' into 1.10.x

commit 548b5d7
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Fri Oct 21 09:37:07 2016 +0200

    - Method renamed
    - try catch removed

commit 54a1bdf
Merge: b7ee130 794b9b0
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 17:51:29 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/5790_partecipate_in_cache_key_generation' into 1.10.x

commit 794b9b0
Merge: 1dcee8a 350cbbd
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 17:44:35 2016 +0200

    Merge branch 'feature/5790_partecipate_in_cache_key_generation' of https://github.com/LaserSrl/Orchard into feature/5790_partecipate_in_cache_key_generation

commit 1dcee8a
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 16:30:12 2016 +0200

    - typo chaching > caching

    - added EventHandler in order to partecipate in cachekey generation

commit 350cbbd
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 17:40:58 2016 +0200

    - typo chaching > caching

commit b7ee130
Merge: c9e14f9 58e59e2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 16:32:13 2016 +0200

    Merge remote-tracking branch 'remotes/Laser.Orchard/feature/5790_partecipate_in_cache_key_generation' into 1.10.x

commit 58e59e2
Author: HermesSbicego-Laser <hermes.sbicego@laser-group.com>
Date:   Wed Oct 19 16:30:12 2016 +0200

    - added EventHandler in order to partecipate in cachekey generation

commit c9e14f9
Author: matteo.piovanelli <matteo.piovanelli@laser-group.com>
Date:   Mon Oct 17 12:54:53 2016 +0200

    Modified the OutputCache Module based on the enhancement proposed in Issue 5811,
    by adding a VaryByRequestCookies property to the CacheSettingsPart to enable the generation of the Cache Key based on cookies

* Changed the view as reccomended by @sebastienros in his comments

* Added culture information to the contentpickerfield editor view

* Fixed a bug in the handler (!= instead of ==)

* showing displaytext in warnings and notifications rather than content item's id

* Cleanup. I
ContentPickerFieldLocalizationDriver Editor methods are executed correctly on validation errors, so they load the additional javascript correctly

* Content picker localization culture dropdown (#7388)

* Default Tag Cache from HttpContext (#7280)

Fixes #7240

* Bug reading SiteSettings from the Routes class (#7363)

Fixes #7362

* Implements what described in #6688 (#7356)

Fixes #6688

* [Fixes #7378] Fixed tenant name validation regex, not to allow numbers. (#7399)

[Fixes #7378]

* Fix link to dotnetfoundation (#7434)

* Fixed the tenant name validation (#7429)

* Fix DateTime parsed in ISO 8601 format. (#7433)

Fixes #7432

* Rename ModelStateDistionaryExtensions.cs to ModelStateDictionaryExtensions.cs (#7415)

* Rename ModelStateDistionaryExtensions.cs to ModelStateDictionaryExtensions.cs

Fixed spelling in file name

* Update Orchard.Users.csproj

Fixed misspelling.

* Adding the ability to enable HTTP Strict Transport Security from the SSL module, fixes #6612

* [Fixes #7436] Added a using of System.Linq in CSharp scripting. (#7437)

Fixes #7436

* [Fixes #7443] Jobs Queue menu item visibility for site owners only. (#7444)

Fixes #7443

* [Fixes #7446] Orchard.Users - Allow umlauts in UserPart.EmailPattern  (#7447)

Fixes #7446

* ProjectionManager Extension (#7417)

- Defined a new interface IProjectionManagerExtension that inherits from IProjectionManager
- ProjectionManager now implements IProjectionManagerExtension, so we can pass a part to GetCount and GetContentItems
- GetCount and GetContentItems transform the part into a Content token, so you can filter data with informations contained in the Projection itself

* [Fixes #7441] Adapt export steps flag to work with refactored steps (#7442)

Fixes #7441

* [Fixes #6196] Added attachments logic (#7338)

Fixes #6196

* [Fixes #7404] Users own media folder name provider (#7454)

Fixes #7404

* [Fixes ##7430] Added support for culture neutral patterns (#7449)

Fixes ##7430

* Adding ability to remove draft and adding grouping to SummaryAdmin content menu, see #2661 and #2662

These two issues are tightly connected so better to address them at once.

* [Fixes #7427] Fixing Blog Post permission

The SummaryAdmin was not using the dedicated permissions.
The default content handler can convert to the owner variation before the blogpost handler.

Fixes #7427

* [Fixes: #7462] Orchard.OutputCache - Possible NRE in DefaultTagCache ctor when accessing the WorkContext (#7463)

Fixes #7462

* [Fixes #7467] Changed gulpfile to invoke autoprefixer directly instead of through cssnano. (#7470)

Fixes #7467

* [Fixes #4941] Adds Url property to dynamic menu shape (#7468)

Fixes #4941

* [Fixes #7425] Session Locator | Isolation Levels not respected in Sites.config (#7466)

Fixes #7425

* [Fixes #7425] Session Locator | Isolation Levels not respected in Sites.config (#7466)

Fixes #7425

* [Fixes #7451] Encoding of taxonomies in the dynamic forms (#7458)

Fixes #7451

* [Fixes #7413] Refactor taxonomies and terms permissions  (#7456)

Fixes #7413 

* Taxonomies:
 - AdminController: Added Actions to AdminController in order to manage Create/Edit: Only Users with Permission.CreateTaxonomy can Edit/Create a Taxonomy
 - Views/Admin/Index.cshtml: Conditional display of ActionLink Create/Edit in Admin/Index.cshtml based on Permission.CreateTaxonomy
 - Views/Admin/Index.cshtml: Conditional display of ActionLink Delete in Admin/Index.cshtml based on Permission.ManageTaxonomies
 - TaxonomyPartHandler: Adding context.Metadata.EditorRouteValues for Taxonomy
Terms:
 - Paring Action/Permission based on existing Permissions
 - Views/TermAdmin/Index.cshtml: Conditional display of ActionLink Create/Edit/Move/Delete based on right Permissions
 - TermPartHandler: Adding context.Metadata.EditorRouteValues for Taxonomy
AdminMenu:
 - The AdminMenu was shown only if a User had ManageTaxonomies Permission; In that way, Roles who have the Create/Edit/Delete Term Permission could not access Index/Edit forms: specializing permissions on Navigation grants access to users belonging to those Roles.

* Removed redundant check over SiteOwner permission

* [#7396] Implements UnassignRoleActivity (#7414)

Fixes #7396

* [Fixes #7469] Fix tenant restart infinite loop. (#7471)

Fixes #7469

* Extensions are not enabled any more if they can't actually be loaded, fixes #2437

* [Fixes 6890] Admin Menu: fix for "Content" item visibility. (#7464)

Fixes #6890

* Usage of undeclared variables in Link.Edit.cshtml. (#7473)

* Update WidgetCommandsService.cs (#7477)

Removed hard coded override of the RenderTitle property for Menu Widgets.

* [Fixes 7474] Add Canvas in Page commands (#7475)

Fixes #7474.
Create layout with a Canvas root element so it can be edited in the Orchard admin.

* [Fixes 7472] Fix for mp4 file not streaming from Azure blob (#7465)

Fixes 7474 

By default Azure blob storage uses service version "2009-09-19". mp4 files served with this version have to be fully downloaded to play.
More info can be found here http://blog.thoughtstuff.co.uk/2014/01/streaming-mp4-video-files-in-azure-storage-containers-blob-storage/.

* Adds IDecorator functionality (#6233)

* [Fixes #7452] Media Library: Replacing a media item in recent section (#7484)

Fixes #7452

* Orchard.Comments - Rework frontend and fix bugs (#7332)

[Fixes #7212, Fixes #7329]

* Fixing that JobsQueue will fail if there are a large number of tasks, fixes #5365

JobsQueue now works in batches to prevent transaction timeouts and the manual job execution feature uses batches as well. This is a fix for the immediate issue, further Fixes are needed around the background task infrastructure, see the linked issue.

* [Fixes #1531] IThemeSelector.GetTheme() gets called several times. (#7491)

Fixes #1531

* Fixing QueryHints.Empty mutable usage

Fixes #7358

* Fixing settings group info matching

Fixes #7371

* Adding vsvars32.bat is vsvarall cannot be found

* Fixing unit test

* Fixing membership unit tests

* Improved performance of Count Hql queries (#7501)

* Feature/openid (#7420)

* [Fixes #6316] Update Alias when importing AutoroutePart (#7485)

Fixes #6316

* Make each JobsQueue tasks execute in its own transaction, see #5365

* Add UserParameters token object (#7482)

Fixes #7481

* Fixing that the content fields' values in a new content item were reset when building their editor (#7505) (#7507)

Fixes #7505

* Hide Gallery menu items on other tenants than Default. (#7511)

* Fixing Gallery search

Fixes #7497

* Output cache vary by query string modes (#7509)

* Fixed path to .vs folder in .gitignore.

* Updated Gulp package dependencies (except TypeScript).

* Updated Gulp pipeline to use latest version of TypeScript.

This also required a change to flow all .js source files through the TypeScript transpiler and let TypeScript do the concatenation/bundling where applicable. This has the added bonus of catching more errors in plain .js files as the TypeScript compiler applies its structural and semantic understanding of the JavaScript code.

* Fixed redundant double negation in Gulpfile.js.

* Added ability to override TypeScript options from asset manifest.

* Added Gulp asset manifest change detection for non-bundled asset groups.

When running the 'build' task, a non-bundled asset group will now be rebuilt if the asset manifest file itself is newer than any of the output files.

* [Fixes #7515] Add RemoveContentDefinition recipe step (#7516)

* Changed .gitignore to exclude node_modules on all levels.

* Added two new features to Gulpfile.js (see below).

- Added support for separating minified resources by folder instead of by .min suffix.
- Added support for flattening the output directory structure of glob-based asset groups.
- Fixed bug where non-minified .js output files were not EOL normalized.

* Fix the error that was preventing the load of the settings' views of the OpenId features (#7518)

* [Fixes #7348] Changed the SummaryAdmin view to have the same "New Translation" link as the Editor view (#7513)

Fixes #7348

* Glimpse (#7502)

Fixes #5419

* Removed duplicated line in AutomaticDataMigrations.cs (#7522)

Fixes #7521

* Fixing that SpecFlow tests were not ran using the tools from the NUnit NuGet package

* Layouts: Removing incompatible (C# 6) code

* Framework: Removing unused file (ContentManagement\Handlers\IdentifyDependenciesContext.cs)

* Core: Removing empty folders

* Users: Removing unnecessary file copied to the Users module (see UserResolverSelector.cs)

Same change as 5e17db3

* Redis: Improving Redis extensions use of keys (#7532) (#5958 re-applied)

* Framework: Fixing that a non-zero MaxPageSize site setting was not applied when the page size is 0, #7541

* Avoid deleting terms twice just getting the root terms on DeleteTaxonomy method (#7553)

* [Fixes #7479] Unwrapping of TargetInvocationException causes partial stacktrace loss (#7550)

Fixes #7479

* [Fixes #5596] blueprint harvesting caching (#7549)

Fixes #5596

* [Fixes #7486] Possibility of exporting individual Form Submissions (#7495)

* Flushing tasks deletion (#7547)

* Adding feature dependencies to OpenId module (#7526)

* Fixing redirect on tenants with a URL prefix, fixes #4605

* MediaLibrary: Fixing that removing TitlePart from a type with MediaPart causes the type to be unusable due to an implicit dependency, fixes #6047

* Remove long obsoleted IRouteProvider.GetRoutes(), see #3177

* Automatically adding MediaPart to content types if another part depends on it, fixes #4792

* Fixes #7493 TextFieldDriver doesn't export its tag if content is empty (#7510)

* TextFieldDriver doesn't export its tag if content is empty
* Null check implemented , string.Empty returned
* TextFieldDriver doesn't export its tag if content is empty #7493
* TextFieldDriver doesn't export its tag if content is empty #7493

* Added missing project dependency for Orchard.Glimps.

* Recipe description didn't match selected one (#7559)

* Feature to remove a Publish Later task (#7438)

* Added missing SnippetDescriptor property to Snippet element shape.

* Fix validation property name on SiteName (#7567)

Fixes #7565

* Revert "Improved performance of Count Hql queries" (#7563)
@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Mar 1, 2017

Contributor

I was thinking about the case that @jersiovic showed me at harvest.
He had a DynamicForm where:

  • he wanted to synchronize across languages (culture neutral) the layout, in terms of e.g. buttons and textareas and so on, but
  • he had some labels for the different components in the form.

The way I would do this:
Build the form with the correct layout and use tokens for the labels. The label's tokens will "point" to TextFields in the ContentItem.
This may be kind of ugly, in that you would need a ContentType with a bunch of TextFields called Label1, Label2... so that you can use the same contentType for different dynamic forms, and however many of those fields that you put in the contentType will dictate the maximum number of labels that you can have in a form.

Contributor

MatteoPiovanelli-Laser commented Mar 1, 2017

I was thinking about the case that @jersiovic showed me at harvest.
He had a DynamicForm where:

  • he wanted to synchronize across languages (culture neutral) the layout, in terms of e.g. buttons and textareas and so on, but
  • he had some labels for the different components in the form.

The way I would do this:
Build the form with the correct layout and use tokens for the labels. The label's tokens will "point" to TextFields in the ContentItem.
This may be kind of ugly, in that you would need a ContentType with a bunch of TextFields called Label1, Label2... so that you can use the same contentType for different dynamic forms, and however many of those fields that you put in the contentType will dictate the maximum number of labels that you can have in a form.

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Mar 1, 2017

Contributor

Thank you, it is better solution than the one we use based on tokens that get translation from .po files cause in that way the user can change translated texts.
To reduce a bit the ugly feeling maybe we can use a new kind of field called DynamicLayoutLocalizationField which provides us an UI for adding all the pairs (of key-localized text) we need to have accesible from tokens from the dynamic layout in that content item. This field will provide us a way of adding translations for multiple texts in a dynamic layout. Without the need of specifically hide a bunch of fields in frontend through placement cause it by default won't render anything.

I said tor reduce "a bit" the ugly feeling ... it still remains I know :)

Contributor

jersiovic commented Mar 1, 2017

Thank you, it is better solution than the one we use based on tokens that get translation from .po files cause in that way the user can change translated texts.
To reduce a bit the ugly feeling maybe we can use a new kind of field called DynamicLayoutLocalizationField which provides us an UI for adding all the pairs (of key-localized text) we need to have accesible from tokens from the dynamic layout in that content item. This field will provide us a way of adding translations for multiple texts in a dynamic layout. Without the need of specifically hide a bunch of fields in frontend through placement cause it by default won't render anything.

I said tor reduce "a bit" the ugly feeling ... it still remains I know :)

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Mar 1, 2017

Contributor

I would go one step further and have a TokenField, where we can input pairs of Token,Value.
This way it's more generic and can in principle be reused for something not localization-related.
Someplace we may wish to create custom Tokens for our contents. Validations and permissions for something like that could be problematic though, because there are "reserved" tokens we should not overwrite.

Contributor

MatteoPiovanelli-Laser commented Mar 1, 2017

I would go one step further and have a TokenField, where we can input pairs of Token,Value.
This way it's more generic and can in principle be reused for something not localization-related.
Someplace we may wish to create custom Tokens for our contents. Validations and permissions for something like that could be problematic though, because there are "reserved" tokens we should not overwrite.

@jersiovic

This comment has been minimized.

Show comment
Hide comment
@jersiovic

jersiovic Mar 1, 2017

Contributor

Initially I liked your idea, but after think on it more I'm not sure if it will drive to UIs difficult of understand for the user when editing a Content Item based on that Field.

Contributor

jersiovic commented Mar 1, 2017

Initially I liked your idea, but after think on it more I'm not sure if it will drive to UIs difficult of understand for the user when editing a Content Item based on that Field.

@MatteoPiovanelli-Laser

This comment has been minimized.

Show comment
Hide comment
@MatteoPiovanelli-Laser

MatteoPiovanelli-Laser Mar 2, 2017

Contributor

#7592 #7596
Made those two PR to carry what we have so far to dev.

Contributor

MatteoPiovanelli-Laser commented Mar 2, 2017

#7592 #7596
Made those two PR to carry what we have so far to dev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment