rfchange: pagination not number but

During translation, I frequently have to move to an certain word or phrase. Now pagination does help if presented in Alphabetical order but it currently does not. I have to browse many screens just to find the correct page.

please consider this sorting. Thanks

  • Alexander

    Hi @Wouter Jan Kok,

    Reusing translations across different plugins would be a bit difficult.

    Each plugin is a brand new context. Depending on that context, you may want to choose a different word in your translation. It makes sense for very general things (month, days, etc.) to always translate the same, but there's nothing to indicate what makes something considered that general.

    Best regards,

  • Wouter Jan Kok

    @Alexander Rohmann
    True, context is important indeed.

    By providing already translated records, basically nothing is lost. If needed by context, you can always decide to translate anyway.

    But if you start out empty handed, as it is now, you will have to translate them all.

    Just my 'live time membership' point :wink:

    p.s.
    Website userbase is also very important in regard to website usage and therefore translation! Can we somehow personalize 'branding' our translation?
    Example: I use several plugins and my userbase is 6-12 year olds, I need to use different wording.

    By language reuse, one can personalize the basic translation.

  • Wouter Jan Kok

    @Alexander Rohmann
    I would like to explain my thoughts about this a little more. Perhaps it does make sense.

    I see this like a child theme but for language support.

    Select Theme or Plugin
    Select Language
    1)
    After 100% finished translation (so Language is usable already)
    For Paid Members or Points Level xyz now add the option for - Create Private Language Subset.
    Add Owner (current account)
    Add Description field
    Now we can select records and change them into user base\ context specific wording.
    After that.
    Save as - Language_CountryCode_Child

    We can now create more informal translations without wrecking the original.

    2)
    After 100% finished translation (so Language is usable already)
    For Paid Members or Points Level xyz now add the option for - Create Global Language subset.
    Here the user can select the records that will be used in his Global Theme and Plugin Translation Set.
    Save a - Language_CountryCode_Global

    Now also add some feature for loading those translations.

  • Wouter Jan Kok

    @PC

    Thanks for this direct communication option, as I rather give the following text without pushing this through regular open support channels.

    Currently, I'm working on several code merges too support my own website 'development' project. It is hard to participate in this community, as I really fail at being a decent programmer. I therefore started language translation on several plugins, just finished number 15 already and counting. Unfortunately in several plugins I encounter the same records over and over again.

    Records just like\ similar, but not limited to, these.
    • Months
    • Weekdays
    • Countrynames
    • Country specific currency
    • WPMU DEV nag screens
    • Confirmation, yes, no
    • Etc.
    All these records add up, and translate all the same, if used in same context. It would help all translators out there, if it were possible to reuse parts of the translation again. A regular translation will be rather straight forward (verbatim translation), but any website has its own unique look and feel and uses context specific words. Therefore most regular translation will not really fit.

    Would it be possible to use language translations like we can use child themes?

    I call this feature- WPMU Language SubSet. I would like to explain my thoughts about this in a little more detail.

    How could this possibly work.

    Now this feature will add the following information into a single (json perhaps?) file.
    • Add Owner (current account, who is working on the file)
    • Add short description text field
    • Add date or version?
    • I would think this would be some list consisting prefilled records holding recurring words. Add selection box for each record to include or exclude this record.
    • For each installed WPMU DEV supported plugin add overrule translate records, in case someone decide not to use this feature for a specific plugin.
    • It would be awesome if this could work also with non-wpmu dev plugins. Basically enable or disable Language SubSet for ANY plugin.
    Save as - Language_ SubSet
    From within the file, the user can select the records that will be used in his Global Theme and Plugin Translation Set.
    We can now create more informal translations without wrecking the original translation set and reuse previously translated wordlists. Now select records and change them into user base\ context specific wording. Doing so will give the option for personal site branding, after the SubSet file has been created.
    We could use allow and deny rules for selection what can be overruled by this translation set.

    How all this works from user perspective...
    1. Setup WordPress
    2. Install Theme
    3. Install branded child-Theme
    4. Install required plugins
    5. Install general translation files
    6. Install Language_ SubSet
    Configuration:
    Install Language_SubSet_Plugin
    Import Language_SubSet
    Check for Compatible (= Supported) Plugins
    From each loaded Plugins
    Enable or Disable
    Select Which records to EXCLUDE from the Language_Subset (this would overrule translation and put the original text in place)

    Check for Compatible (= Supported) Themes
    From each loaded Themes
    Select Which records to EXCLUDE from the Language_Subset (this would overrule translation and put the original text in place)

    Why this might be good?
    • It will mitigate the stress related to lost translations after each plugin update!
    • It will provide great service for website owners for unique site branding.
    • It might boost translation into other languages.
    • It does help those translators to save time, by language reuse.
    • It adds flexibility in context specific wording. The used words now fit my site.
    • WPMU DEV paid customers always get the right to use. Doing so it might increase WPMU DEV sales also.
    Why is this not good?
    • Maintenance might become hard due to database name changes?
    • Hard to include language records?
    • Increased site footprint, because extra hook needed to pull latest translations?
    • There will be incompatible plugins.

    THANKS!

    p.s. And ABC pagination, instead of 123 during translation.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.