Editor Raw Mode – Suggestions

  • Resolved extremecarver

    (@extremecarver)


    9 years, 2 months ago

    Using latest (as before 1 hour) 2.9.8.9 pre-lease from Github.

    Right now the Raw Mode seems to work fine for me. There is however one problem if switching backward and forward.

    In case I disable raw mode – and then have the qtranslate-x editor with possibility to choose language – upon saving it will replace my [:en] or [:de]shortcodes with the full language html tags before and after…

    It does not make much sense to use full html version using raw editor mode – because it get’s hacky to see what’s going on.

    So some solutions that would work:
    a) if raw mode enabled – convert all language tags to shortcodes in the editor (at least in the frontend).

    b) Never convert from shortcodes to full language tags with raw mode disabled (probably the easiest solution).

    c) add option whether shortcodes or full language tags are set by default.

    Feature Request/Suggestion
    — As a general thought. Raw Mode is great because at least I think it is the most robust. Now here comes a suggestion that would make it a semi-raw-mode kinda, but really useful.

    Often I have many pictures/link lists/tables in my website – that don’t need any translation (yes I know – changing the tags of an image in language too is nice for SEO, but really I cannot think it is worth the effort for me). Now the way qtranslate works is that we define languages and then add everything for each language.

    I would love to have a stop translate shortcode and the following behaviour

    [:/langauge]….content for all languages – e.g. pics, tables, links
    [:en] English text/content
    [:de] German text/content
    [:/language]… again cotent for all languages
    [:en] English text/content
    [:de] German text/content

    and so on. This would really save me time translating posts/pages. Now while this would probably be difficult to enable for single language editor modes – it would really be cool for using raw editor mode. Maybe it could even reduce the performance penalty of qtranslate? Now this feature suggestion is not so important as fixing the above problem, but would be very cool.

    https://wordpress.org/plugins/qtranslate-x/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter extremecarver

    (@extremecarver)

    9 years, 2 months ago

    Oh yeah – in general Qtranslate-X works great for me. Besides that I will need to rework lot’s of pages due to using fckeditor before, and now tinymce – and tinymce is often dropping linebreaks, or adding linebreaks when reading in content created by fckeditor. (basically I need to first open the page in text mode, save it – and only then I can open it in visual mode – otherwise tinymce crashes the formating).

    Plugin Author John Clause

    (@johnclause)

    9 years, 2 months ago

    Yes, I was thinking about [:/language] myself too. In fact, I am not sure why there are two modes <:> and [:]. It might be just a historical reason, which nobody wanted to put in order. If we indeed add [:], for example, as closing tag in [:]-mode, then we do not really need <:> mode. The original author has probably started with comment-like <:> mode, because it hides tags in HTML, which seems cool, then he realised that <:> tags do not survive esc_html() function, and he came up with [:] mode as a backup for the case when <:> gets broken.

    If he had also introduced closing tag in [:] mode, the two modes would be completely interchangeable (with the exceptions of reaction to esc_html). I have some cases, where I have to switch the mode depending on where the text goes from the same source – very inefficient.

    I was afraid to do a drastic change, because one will not be able go back to old qTranslate and other forks easily enough, but maybe it is time to forget old q and other forks and just do whatever makes best sense, which is introducing [:] as closing tag in [:]-mode and forgetting <:>-mode completely?

    And we would not need to put closing tag [:] right before another language opening tag like [:en], as it is in now in <:>-mode.

    Can you see any dangerous possible consequences in doing so?

    Thread Starter extremecarver

    (@extremecarver)

    9 years, 2 months ago

    From a user point – I cannot see any dangerous consequence in doing so..

    As long as the new method is well documented – other forks should be able to implement it too I would think.

    The main thing for me is – as soon as [:] mode is also having a closing tag – the raw editor mode starts to really be at an advantage over the split language view.

    Because right now with split language windows (no matter how they are implemented) – the closing <:> doesn’t really offer any sense – except to keep it working. On the other hand in raw editor mode <:> is invisible except if switching from html to ext viewmode.

    Maybe even a script to change all <:> to [:] would be good – and then dropping <:> eventually in future except if someone sees a real reason to keep it?

    Oh yeah – and thanks for the reply! I actually did not even know the technical reason for the <> shortcoming. To me it was simply about usability (and [] working more consistently)

    Plugin Author John Clause

    (@johnclause)

    9 years, 2 months ago

    @extremecarver: The latest on GitHub (3.1-b1) has [:] ending tag. Also it has an option to convert db to [:]-only mode. Could you try it?

    Plugin Author John Clause

    (@johnclause)

    9 years, 1 month ago

    There is a newer version now at GitHub. Have you tried anything? Please, let me know either way.

    Thread Starter extremecarver

    (@extremecarver)

    9 years, 1 month ago

    I haven’t had time to do it so far. Right now starting to play around with it however…

    Thread Starter extremecarver

    (@extremecarver)

    9 years, 1 month ago

    Hi John,
    sorry for the delay but I did not really have enough time so far. Here are my findinds/opinions so far.

    1. Great step forward. Love that the new default for pages is [:] mode and the [:] as ending is really nice.

    2. Moving forward and backward with editor raw mode to normal mode works fine too. Only of course if you had used content for all languages – once going back to raw text previously ented in raw after [:] as closing will be inside the own language section. Well I guess that’s the only way to do it – as there is no way to know anymore that a certain section belonged to all languages (and even some invisible tag would be bad – because of course if for one language the all language section were edited – it would break somewhere). Maybe this should be better explained (using [:] to end the language and then inserting text for all languages – will be converted to each single language if you enable the normal mode (as opposed to editor raw mode).

    3. There is a little bug that I discovered however. Reproducable like this. Editor raw mode enabled. Go to any page in secondary lanugage (website frontend) and click on Edit in the top WordPress bar (as your account is using primary language you will edit using primary language interface – dunno if editing user language matters though). Then click on Publish – and click on “View Page”. Not the page will not show up! (all content just blank). Even copying the link and entering it again does not help. Solution click on the change language selector and on another language. Now it will work again – but you are transferred to the “Home Page” in the newly chosen language. As this bug does not affect end users – it’s not such a big problem – but a bit confusing/annoying still.

    4. I’m at war with the standard editor. My pages really get broken as soon as I edit any page with it in “Visual” Mode. But I guess this is not a problem of qtranslate-x but of fckeditor used before. If I use the “Tiny MCE Advanced” plugin though – everything works fine. I can insert empty lines again, and my old empty lines are not deleted, and so on. So I can finally move from mqtranslate with the oudated “Deans FCK Editor” to qtranslate-x and Tiny MCE Advanced. Everything works well enough to go live with this setup I think.

    5. A button to convert all <:> to [:] would be nice to have. But I don’t have many occurences of <:> anyhow.

    For the long run – once 3.1 is working for everyone good enough:
    (6. once converted to [:] make editor raw mode default – it’s really the quickest way to translate pages. Badly my server is far to overpowered to see if there are performance benefits of this too… (dunno how all language text is saved in the database. Is it still saved for each language separately or not?.

    Plugin Author John Clause

    (@johnclause)

    9 years, 1 month ago

    Thanks a lot for the response and testing, @extremecarver.

    I could not reproduce #3 though, it worked for me, but I am using the latest development, not sure if it matters. Could you try it with the currently latest?

    For #5, the latest development does more conversion, as described in https://qtranslatexteam.wordpress.com/2015/02/25/options-convert-database/.

    #6 – I believe the vast majority of users will disagree with you to make raw mode to be default, but they will still benefit from ending tag [:] in a number of ways 🙂

    Thanks a lot, @extremecarver, for a very useful discussion.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Editor Raw Mode – Suggestions’ is closed to new replies.