> As stated it would be good to move this forward but in the correct
> architectural manner. 
Sure, that's why I'm posting to list :-)

> 
>     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.
I'm currenlty focussing on getting the importers to import multiple
languages.
I started with Songbeamer because that's the one I know.
I started a branch here: lp:~thelinuxguy/openlp/multi-language
(currently Songbeamer songs should be imported splitting the verses
according to languages)
After the importers are done, I'll work on updating the editors
>     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.
I guess the simplest would be to split the display into regions, and
have options to choose how to split it. I'm not that familiar with the
code yet so I don't know how easy/hard interleaving is to implement, but
sometime in the future I would like to have it as an option :-)

>     If we could avoid messing with the themes, that would be great :)
Noted :D

>     > 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
Ok OpenLyrics it is
>     > 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
Thanks, I'll look into them

> A couple of years ago I thought about the implementation of this feature and
> documented my ideas in the wiki:
>
> http://wiki.openlp.org/Scratchpad:Implementation_of_Parts_and_Translations
>
> This thoughts should be reflected with the current code base in mind, but I
> think most ideas are still valid.

I guess the main issues with the suggestions are OpenLyrics and not
messing with the themes... Transliterations and parts are not so
important for me, so I would prefer to first get translations in

> However I do wonder if in at least some situations there would be
> advantages in having the option of a second presentation
> screen/projector. Thus one projector would show one language while the
> other projector would show another language. In such a configuration
> then all the existing themes/layout/etc would still apply as they
> currently do. There would of course be some complications such as trying
> to make sure slide breaks are in the same place across languages, etc.

Nice Idea, I don't know if multi-monitor support is somewhere on the
roadmap of OpenLP but it sounds great!


_______________________________________________
openlp-dev mailing list
[email protected]
https://lists.openlp.io/mailman/listinfo/openlp-dev

Reply via email to