Re: [Tiki-devel] A user friendly way to edit content within templates
Bernard Sfez via TikiWiki-devel <[email protected]>
| Newsgroups | gmane.comp.cms.tiki.devel |
|---|---|
| Message-ID | <[email protected]> |
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.
… 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