The translations need to be added in the Songs plugin as this is part of the architecture of OpenLP.
Songs, Bibles and Custom provide a string of text which can be rendered into a set of display frames. The plugings create a service item which holds the text and provides it to the display parts of the system. After the service item has been created the type of plugin is immeterial, we have text. The service item will trigger a render at given times and the text will be split up into actual pages to display. At this point Screen size / Themes and formatting come into play. The renderer works out where additional page breaks need to be added. We already support dual languages in Bibles but this has limitations on 1 verse per slide and a smallish font. To reduce the disturbance to the core code translations should be done in the relevant plugins and leave the core code alone unless there is good reason to. As stated it would be good to move this forward but in the correct architectural manner. On 4 January 2016 at 13:59, Tomas Groth <[email protected]> wrote: > Hi Simon, > > Like the others I'm glad that you have started looking into this, and I > hope you can make some progress on this :) > > > I pretty much agree with Andreas' post below on expanding the internal use > of OpenLyrics to include support of translations. I also like the idea of a > side-by-side editor for multiple translations. > > You mention that configuring the presentation of a songs translations > could be done after it is added to the servicemanager, but I think should > be handled in the standard song-editor, since the information must also be > available when presenting a song directly from the mediamanager. Some > customization could be done in the servicemanager like you propose. > > Regarding the presentation I would propose that if a song contains more > than one active language/translation, the presentation area on the display > is divided equally between those translations. So if there are 3 different > translations there will be 3 different presentation areas. These area could > be arranged horizontally or vertically, perhaps determined by an option > somewhere. I must admit that I'm personally not a big fan of interleaved > text in this case, but that doesn't mean it shouldn't be an option. > > If we could avoid messing with the themes, that would be great :) > > Best regards, > Tomas (tgc) > > > ----- Original Message ----- > > From: googol <[email protected]> > > To: [email protected] > > Sent: Monday, January 4, 2016 12:11 PM > > Subject: Re: [openlp-dev] Support for multiple languages > > > > Hey Simon, > > > > Two thought from me: > > > > 1) We support (export/import) and use (internally) OpenLyrics [1] for > > exchanging lyrics. So that should be considered when implementing this. > > The point is, that OpenLyrics stores a song and its translations in one > > file, so it might be better (?) to implement a). Look at the lyrcis > > field in the database and compare it the OpenLyrics: > > http://openlyrics.info/dataformat.html#song-lyrics > > > > 2) A new editor would be cool. Somebody (and later myself) experimented > > with a new editor. There are both buggy and experimental, but might give > > you some inspiration. > > > > https://code.launchpad.net/~m2j/openlp/editor > > https://code.launchpad.net/~googol/openlp/new-editor > > > > Cool that you are looking at this, I think it's a big and important > > (missing) feature for OpenLP :) > > > > Regards > > > > > > [1] http://openlyrics.info/ > > > > Am 04.01.2016 um 11:32 schrieb Simon Hanna: > >> Hi all, > >> > >> this is supposed to be a discussion about how multiple languages could > >> be supported. > >> > >> I think there are two descisions to be made: > >> 1. How to store multiple languages > >> 2. How to display multiple languages > >> > >> Here come my opinions: > >> 1. There are two options. > >> a) Store multiple languages together (something like Songbeamer) > >> b) Keep them separated but link them together > >> > >> Since OpenLP has a database, I guess option b would be nice as each > song > >> would still remain there on itself. Also all the copyright information > >> specific to languages could be stored for each language on its own. > This > >> would make OpenLP support an infinite number of languages > >> > >> 2. The different options I came across till now are interleaving or > >> putting one below the other. I'm familiar with interleaving so I would > >> vote for that. > >> > >> > >> About implementation: > >> I would enhance the editor to show two songs side by side, so multiple > >> langauges can be editted at the same time. > >> I'm not sure if it's viable to solve the displaying issue in > > themes. > >> The upside would be that every one can display it the way they want. > >> > >> The songs in the database would get two attributes Language and a > >> song-id used to identify songs. Songs with several languages would then > >> have the same song-id but different language > >> > >> Once a song is in the ServiceManager there should be an option to > choose > >> what languages to display. It should also include ordering and maybe > how > >> to display interleaved or one after the other. > >> > >> The settings could include an option to set the default languages to > >> display. > >> > >> > >> What do you think? > >> > >> cheers, > >> Simon > >> _______________________________________________ > >> openlp-dev mailing list > >> [email protected] > >> https://lists.openlp.io/mailman/listinfo/openlp-dev > > > > > > _______________________________________________ > > openlp-dev mailing list > > [email protected] > > https://lists.openlp.io/mailman/listinfo/openlp-dev > > > _______________________________________________ > openlp-dev mailing list > [email protected] > https://lists.openlp.io/mailman/listinfo/openlp-dev > -- Tim and Alison Bentley [email protected]
_______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev
