C# Class Bloom.Book.TranslationGroupManager

Most editable elements in Bloom are multilingual. They have a wrapping
and then inner divs which are visible or not, depending on various settings. This class manages creating those inner divs, and marking them with classes that turn on visibility or move the element around the page, depending on the stylesheet in use. Also, page
s are marked with one of these classes: bloom-monolingual, bloom-bilingual, and bloom-trilingual
The Mother said...
Mama i tok:
abada fakwan
Show file Open project: BloomBooks/BloomDesktop Class Usage Examples

Public Methods

Method Description
PrepareDataBookTranslationGroups ( XmlNode pageOrDocumentNode, IEnumerable languageCodes ) : void

Normally, the connection between bloom-translationGroups and the dataDiv is that each bloom-editable child (which has an @lang) pulls the corresponding string from the dataDiv. This happens in BookData. That works except in the case of xmatter which a) start empty and b) only normally get filled with .bloom-editable's for the current languages. Then, when bloom would normally show a source bubble listing the string in other languages, well there's nothing to show (the bubble can't pull from dataDiv). So our solution here is to pre-pack the translationGroup with bloom-editable's for each of the languages in the data-div. The original (an possibly only) instance of this is with book titles. See bl-1210.
PrepareElementsInPageOrDocument ( XmlNode pageOrDocumentNode, CollectionSettings collectionSettings ) : void

For each group of editable elements in the div which have lang attributes (normally, a .bloom-translationGroup div), make a new element with the lang code of the vernacular (normally, a .bloom-editable). Also enable/disable editing as warranted (e.g. in shell mode or not)
SetInitialMultilingualSetting ( BookData bookData, int oneTwoOrThreeContentLanguages, CollectionSettings collectionSettings ) : void

This is used when a book is first created from a source; without it, if the shell maker left the book as trilingual when working on it, then every time someone created a new book based on it, it too would be trilingual.
UpdateContentLanguageClasses ( XmlNode elementOrDom, CollectionSettings settings, string vernacularIso, string contentLanguageIso2, string contentLanguageIso3 ) : void

We stick 'contentLanguage2' and 'contentLanguage3' classes on editable things in bilingual and trilingual books

Private Methods

Method Description
GetOrderOfThisLanguageInTheTextBlock ( string editableIso, string vernacularIso, string contentLanguageIso2, string contentLanguageIso3 ) : int
MakeElementWithLanguageForOneGroup ( XmlElement groupElement, string isoCode ) : void

For each group (meaning they have a common parent) of editable items, we need to make sure there are the correct set of copies, with appropriate @lang attributes
PrepareElementsOnPageOneLanguage ( XmlNode pageDiv, string isoCode ) : void
RemoveXmlChildren ( List removalList ) : void
ShouldNormallyShowEditable ( string lang, string dataDefaultLanguages, string contentLanguageIso2, string contentLanguageIso3, CollectionSettings settings ) : bool

Here, "normally" means unless the user overrides via a .bloom-visibility-user-on/off
StripOutText ( XmlNode element ) : void

Remove nodes that are either pure text or exist only to contain text, including BR and P Elements with a "bloom-cloneToOtherLanguages" class are preserved
UpdateRightToLeftSetting ( CollectionSettings settings, XmlElement e, string lang ) : void

Method Details

PrepareDataBookTranslationGroups() public static method

Normally, the connection between bloom-translationGroups and the dataDiv is that each bloom-editable child (which has an @lang) pulls the corresponding string from the dataDiv. This happens in BookData. That works except in the case of xmatter which a) start empty and b) only normally get filled with .bloom-editable's for the current languages. Then, when bloom would normally show a source bubble listing the string in other languages, well there's nothing to show (the bubble can't pull from dataDiv). So our solution here is to pre-pack the translationGroup with bloom-editable's for each of the languages in the data-div. The original (an possibly only) instance of this is with book titles. See bl-1210.
public static PrepareDataBookTranslationGroups ( XmlNode pageOrDocumentNode, IEnumerable languageCodes ) : void
pageOrDocumentNode System.Xml.XmlNode
languageCodes IEnumerable
return void

PrepareElementsInPageOrDocument() public static method

For each group of editable elements in the div which have lang attributes (normally, a .bloom-translationGroup div), make a new element with the lang code of the vernacular (normally, a .bloom-editable). Also enable/disable editing as warranted (e.g. in shell mode or not)
public static PrepareElementsInPageOrDocument ( XmlNode pageOrDocumentNode, CollectionSettings collectionSettings ) : void
pageOrDocumentNode System.Xml.XmlNode
collectionSettings Bloom.Collection.CollectionSettings
return void

SetInitialMultilingualSetting() public static method

This is used when a book is first created from a source; without it, if the shell maker left the book as trilingual when working on it, then every time someone created a new book based on it, it too would be trilingual.
public static SetInitialMultilingualSetting ( BookData bookData, int oneTwoOrThreeContentLanguages, CollectionSettings collectionSettings ) : void
bookData BookData
oneTwoOrThreeContentLanguages int
collectionSettings Bloom.Collection.CollectionSettings
return void

UpdateContentLanguageClasses() public static method

We stick 'contentLanguage2' and 'contentLanguage3' classes on editable things in bilingual and trilingual books
public static UpdateContentLanguageClasses ( XmlNode elementOrDom, CollectionSettings settings, string vernacularIso, string contentLanguageIso2, string contentLanguageIso3 ) : void
elementOrDom System.Xml.XmlNode
settings Bloom.Collection.CollectionSettings
vernacularIso string
contentLanguageIso2 string
contentLanguageIso3 string
return void