Re: [Tiki-devel] A user friendly way to edit content within templates

Hi Bernard

I've read this several times but still don't quite understand - tiki will pick a version of the ("parent") page automatically for you depending on the user's language pref, so i'm not sure why you're not using that?

I.e. you have HomePage_en, HomePage_fr and HomePage_he, each of those can contain it's own banner page surely? (although i might use modules for banners, but whatever...).

Maybe you want to use the same tpl to be used for all langs, but i still don't see the problem, just use {tr}translate tags{/tr} in them?

Adding automatic "best translated page" picking to plugin include might help maybe?

Perhaps something to discuss in the next roundtable?

jonny



> On 27 Sep 2021, at 05:43, Bernard Sfez via TikiWiki-devel <[email protected]> wrote:
> 
> Adding some thoughts and informations after more test…
> 
> Note that we got a bit of every thing but I couldn’t find the right dosage between UX and Administration.
> 
> 
> 
> 1/ The include solution
> 
> As describe previously this is quite complicate to put that all in place.
> However using the “edit” plugin inline permission and the edit icon the super user can edit in context any included page.
> (The user can use the edit plugin include icon to edit the included page but can’t edit the page)
> 
> I could even trick Tiki by making the plugin to offer an option to create a missing content (page).
> 
> {include page="Test_text_en" nopage_text="Create ((Test_text_en))" page_edit_icon="y" page_replace_icon="n"}
> 
> So this is quite a good solution for the user (UX).
> Maintaining and setting is very heavy and require a lot of manual operation + playing with permission (the super user should have global wiki edit but then restricted on page or category level).
> A year from now it will be 😱
> 
> 
> 2/ The custom (file) translate solution
> 
> Using the html interface for custom translations at tiki-language-manage_custom_translations it is possible to change translated string.
> 
> So eventually we could have a Tiki in English primarily and translations can be done by a super user. (We don’t want to give users or translators admin access).
> 
> But:
> 
> What about the primary language ?
> I know of some other application where strings are set by location IE:
> Homepage_title
> Homepage_topBanner
> Homepage_text
> 
> I imagine we could trick Tiki with a “fake language”, like a system language and have:
> 
> System | en
> Homepage_title => Welcome
> Homepage_topBanner => This website is a Tiki
> Homepage_text => Long bla bla…
> 
> Then at tiki-language-manage_custom_translations super user will be able to edit everything. (With permissions)
> 
> This is a tricky way to translate things. (Not in context)
> 
> Not sure this is a good possible solution... ;-)
> 
> 
> 3/ The custom database translate + interactive translation solution
> 
> I thought about using the interactive translation but it went to a short test;
> 
> - Working only with Tiki classic layout (no go for me, I use classic bootstrap for almost all my Tikis now)
> - It is “translate Tiki strings” oriented, seems I have to enter manually ALL the strings in the database one by one.
> 
> <Screen Shot 2021-09-27 at 7.36.20.png>
> 
> 
> … Mixing (and fixing) option 2 + 3 working together could be the right way to go in 2021.
> Still unsure if I like using generic string (Homepage_title)
> 
> Bernard
> 
> 
> 
> 
>> On 26 Sep 2021, at 8:55, Bernard Sfez via TikiWiki-devel <[email protected]> wrote:
>> 
>> Hello,
>> 
>> Tiki is very strong fro managing plain Wiki pages.
>> But sometimes you need to use templates (smarty or wiki tpl) to create a Tiki website that includes advanced design and search tools.
>> 
>> In such case, you want to “protect” the page from editing and being open (the user don’t need to see what is under the hood) while having the easiest possible way for the user to edit the page content.
>> I started experimented things and a working way I found is to use templates + wikiplugin includes + lang pref + wiki page.
>> 
>> IE:
>> 
>> In a smarty template I have:
>> <p>
>>    {if $prefs.language eq "fr"}
>>        {wikiplugin _name=include page="HomePage_banner_fr" nopage_text=“Contenu à ajouter..." page_edit_icon="y"}{/wikiplugin}
>>    {elseif $prefs.language eq "he"}
>>        {wikiplugin _name=include page="HomePage_banner_en" nopage_text=“תוכן חסר..." page_edit_icon="y"}{/wikiplugin}
>>    {else}
>>        {wikiplugin _name=include page="HomePage_banner_en" nopage_text="Content to be added..." page_edit_icon="y"}{/wikiplugin}
>>    {/if}
>> </p>
>> 
>> Then I have 3 wiki pages for the content (I tried to use one page with 3 include sections per language it was confusing for the user and it may be not the same user that edit a language) 🥴 in a “Website content” structure.
>> Plus 3 wiki page for each language.
>> 
>> All this is working fine however it is quite complicate, more fragile than needed, more expensive (time is money) than expected, they may be some side effects on SEO (pages indexed ?), etc.
>> 
>> Someone see a clever way ?
>> 
>> Bernard
>> 
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> 
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel