Child pages
  • Automatic phrase type based on it's name
Skip to end of metadata
Go to start of metadata

Imported from:

I think, that we need a way for In-Portal to automatically guess phrase type based on:

  • user action (that leads to user to phrase adding/editing screen)
  • phrase name (that is entered by user)

By User Action

  • translation phrase while on Front-End (special translate link OR orange edit button) - "Front-End" type;
  • toolbar button "Add" click in phrase list in administrative console - "Admin" type.

By Phrase Name

  • phrase name starts with "lu_" - "Front-End" type;
  • phrase name starts with "la_" - "Admin" type.

Detection by phrase name overrides detection by user action, since it's bad style to mark phrases, that starts with "lu_" belonging to administrative console. 

When both "Phrase Name" and "Phrase Type" fields are visible on phrase adding/editing form, then I also suggest to place "*onblur*" event on "Phrase Name" field to change "Phrase Type", when user starts to enter phrase translation.

In this case we could make "Phrase Type" field read-only to user. There is one small problem with that: phrases, that have "Both" type. We should eliminate that as soon as possible, but in this scheme their type will be changed automatically based on their name.

Related Tasks

INP-826 - Getting issue details... STATUS


  1. I like the idea - sounds like feature for 5.2.0 or future.

    Here is the list of phrase with Both type:

    <PHRASE Label="la_importlang_phrasewarning" Module="Core"
    Type="2"><![CDATA[Enabling this option will undo any changes you have made
    to existing phrases]]></PHRASE>
    <PHRASE Label="la_PhraseType_Both" Module="Core"
    <PHRASE Label="la_prompt_DupRating" Module="Core" Type="2"><![CDATA[Allow
    Duplicate Rating Votes]]></PHRASE>
    <PHRASE Label="la_prompt_DupReviews" Module="Core" Type="2"><![CDATA[Allow
    Duplicate Reviews]]></PHRASE>
    <PHRASE Label="la_prompt_overwritephrases" Module="Core"
    Type="2"><![CDATA[Overwrite Existing Phrases]]></PHRASE>
    <PHRASE Label="la_Text_backup_access" Module="Core"
    Type="2"><![CDATA[In-Portal does not have access to write to this
    <PHRASE Label="la_Text_Invalid" Module="Core"
    <PHRASE Label="la_Text_Not_Validated" Module="Core" Type="2"><![CDATA[Not
    <PHRASE Label="la_users_subscriber_group" Module="Core"
    Type="2"><![CDATA[Assign mailing list subscribers to group]]></PHRASE>
    <PHRASE Label="lu_field_cachedrating" Module="Core"
    <PHRASE Label="lu_field_cachedreviewsqty" Module="Core"
    Type="2"><![CDATA[Number of Reviews]]></PHRASE>
    <PHRASE Label="lu_field_cachedvotesqty" Module="Core"
    Type="2"><![CDATA[Number of Rating Votes]]></PHRASE>
    <PHRASE Label="lu_field_createdbyid" Module="Core" Type="2"><![CDATA[Created
    By User ID]]></PHRASE>
    <PHRASE Label="lu_field_createdon" Module="Core" Type="2"><![CDATA[Date
    <PHRASE Label="lu_field_description" Module="Core"
    <PHRASE Label="lu_field_hits" Module="Core"
    <PHRASE Label="lu_field_hotitem" Module="Core" Type="2"><![CDATA[Item Is
    <PHRASE Label="lu_field_lastpostid" Module="In-Bulletin"
    Type="2"><![CDATA[Last Post ID]]></PHRASE>
    <PHRASE Label="lu_field_linkid" Module="Core" Type="2"><![CDATA[Link
    <PHRASE Label="lu_field_manufacturer" Module="In-Commerce"
    <PHRASE Label="lu_field_modified" Module="Core" Type="2"><![CDATA[Last
    Modified Date]]></PHRASE>
    <PHRASE Label="lu_field_modifiedbyid" Module="Core"
    Type="2"><![CDATA[Modified By User ID]]></PHRASE>
    <PHRASE Label="lu_field_name" Module="Core"
    <PHRASE Label="lu_field_newitem" Module="Core" Type="2"><![CDATA[Item Is
    <PHRASE Label="lu_field_notifyowneronchanges" Module="Core"
    Type="2"><![CDATA[Notify Owner of Changes]]></PHRASE>
    <PHRASE Label="lu_field_orgid" Module="Core" Type="2"><![CDATA[Original Item
    <PHRASE Label="lu_field_ownerid" Module="Core" Type="2"><![CDATA[Owner User
    <PHRASE Label="lu_field_popitem" Module="Core" Type="2"><![CDATA[Item Is
    <PHRASE Label="lu_field_postedby" Module="In-Bulletin"
    Type="2"><![CDATA[Posted By]]></PHRASE>
    <PHRASE Label="lu_field_priority" Module="Core"
    <PHRASE Label="lu_field_resourceid" Module="Core" Type="2"><![CDATA[Resource
    <PHRASE Label="lu_field_status" Module="Core"
    <PHRASE Label="lu_field_topicid" Module="In-Bulletin"
    Type="2"><![CDATA[Topic ID]]></PHRASE>
    <PHRASE Label="lu_field_topictext" Module="In-Bulletin"
    Type="2"><![CDATA[Topic Text]]></PHRASE>
    <PHRASE Label="lu_field_url" Module="Core" Type="2"><![CDATA[URL]]></PHRASE>
    <PHRASE Label="lu_of" Module="Core" Type="2"><![CDATA[of]]></PHRASE>

    I'll work through it to make sure LA or LU indicates where it's used and we
    don't have missing phrases after we implement this functionality.


  2. I began thinking about bringing "Both" type back to life already some
    time ago. If we'll use it in correct way, marking all phrases used
    both on front-end and back-end (for ex., field options like
    la_opt_Yes, la_opt_No), it would make much sense for translators. In
    several cases translator wants to translate only front-end phrases
    (when there are few languages on website and only one language
    actually used in administrative console). There also may be cases when
    only back-end phrases are to be translated. So, marking la_opt_Yes as
    admin phrase hides it from front-end translator who uses type filter,
    but phrase actually may be used on front-end also, if same field's
    value is outputted somewhere on front-end. Using "Both" type would
    make it more clear.
  3. So you think, that "Both" phrase type isn't so bad after all.

    Maybe we should invent new phrase name prefix like "lc_" (label common) or
    "lb_" (label both) to indicate, that phrase is used both on Front-End and

    In this case we can still guess phrase type by it's name. What do you think,

    Some phrases, like "la_prompt_DupRating" are surely a configuration variable
    name, that is visible only in Administrative console, but is used to
    configure forms on Front-End only, so it will became "Admin" type for sure.
    However phrases like "lu_field_cachedvotesqty" are used as search field
    names, that is visible in search settings section in administrative console
    and on advanced search form on Front-End.

  4. Also, one note about auto-detection phrase type in conjunction with
    using "Both" type: we may add "type" parameter to m_Phrase tag, so in
    case if it's given, it overrides auto-detection.
  5. Presuming, that "lc_" or similar phrase prefix will be invented, then we no
    longer need phrase type detection by user action.

    It's really important for me to know, so I repeat my question:

    *Maybe we should invent new phrase name prefix like "lc_" (label common) or
    "lb_" (label both) to indicate, that phrase is used both on Front-End and
    Admin.* This way we could make Phrase Type field read only for sure on
    phrase adding/editing form.

  6. Yes, we may add lb_/lc_ prefix also, but it will result in current
    label renaming, which includes changing labels in templates and code.
    It's too complicated, may be we can apply it for new labels only?
  7. I think that we will apply that new phrase name prefix to phrases on
    question for now (ones that have "Both" type right now) and in time we will
    scan at least all options of fields to rename phrases.

    Most problems will be with "la_Yes" and "la_No" phrases, that will be
    renamed to "lb_opt_Yes" and "lb_opt_No" and most people have them hardcoded
    in their custom unit configs.

    Sometimes little sacrifice must be made for a better future. I home
    sometimes In-Portal will be complaint to it's own naming standards.

  8. Let's revisit this discussion.

    Alex, as I understand this will stop Developer from ability force Label to
    one of 3 types as they can now and will be done automatically.

    What are the down sides of this, if any?


  9. This we note phrase usage in it's name by "lc_" prefix, so translator will
    know, that such a phrase is used on both Front-end and Admin Console.

    Since phrase type will be 100% automatically determined by it's name (which
    is checked against regular expression now in 5.1.1+ versions), then no
    human-mistake could be made.

    We could even prevent "la_" phrases from being used on Front-end at all
    (need to review whole language pack to ensure that this will work without

    On Sun, Feb 20, 2011 at 4:42 AM, Dmitry A. <> wrote:
    > Let's revisit this discussion.

    > Alex, as I understand this will stop Developer from ability force Label to
    > one of 3 types as they can now and will be done automatically.

    > What are the down sides of this, if any?

    > DA

  10. Thanks for reminding and explaining.

    I am all for it!

    I say we can introduce this starting 5.2.0 if you don't mind.


  11. We can introduce it even before that.

    On Sun, Feb 20, 2011 at 8:52 PM, Dmitry A. <> wrote:
    > Thanks for reminding and explaining.

    > I am all for it!

    > I say we can introduce this starting 5.2.0 if you don't mind.

    > DA

  12. ok.

    On Sun, Feb 20, 2011 at 8:53 PM, Dmitry A. <> wrote:
    > Ok, how about 5.1.3 then?

    > DA

  13. Alex, would you please create a task for this?

    Don't want this discussion to get lost.


  14. Task:

    INP-826 - Getting issue details... STATUS


    INP-826 - Getting issue details... STATUS


    On Mon, Feb 28, 2011 at 8:01 PM, Dmitry A. <> wrote:
    > Alex, would you please create a task for this?

    > Don't want this discussion to get lost.

    > DA

  15. I've recently noticed, that lack of this automatic phrase type detection
    leads to tons of phrases designated for Admin Console usage (with "la_"
    prefix) having a "Front-end" type set upon their creation.

    Since currently no automatic check is made, then user/developer could create
    a lot of misleading phrases (marked for admin user, but having front-end
    type and vice versa).

  16. that's right, specially when using the special page for translating while
    surfing on front end, where user will likely not select any phrase type in

    What do you propose here? A little script which read all phrases labels in
    theme and set them to "front" if they are set to "admin"?
    Or just adjust phrase type using their prefix la or lu ?

    2011/9/2 Alexander Obuhovich <>

  17. I'm proposing to:

       1. add "lc_" phrase prefix for phrases that can be used in both front-end
       and admin
       2. make Type field of phrase set automatically based on phrase start
       "lu_", "la_", "lc_"

    This way no mistakes and you export front-end and admin language packs
    without any problems.

    Your idea about "little upgrade script", that would fix any mistakenly
    created phrases is useful too.

  18. what would mean "c"? I was thinking about "lb_" for Language for Both

    I though about this script before, because I was also thinking it cloud
    clean the lang pack: each front-end label not found in theme would be
    deleted. This would be a maintenance script, which could also apply for
    admin theme, in case users have chosen the wrong label type.

    2011/9/2 Alexander Obuhovich <>

  19. "c" means "*c*ommon for both front-end and admin" (that one is described in
    previous posts).

    Detecting which phrases are actually used isn't easy task, since phrase
    could be used even if it's label isn't mentioned in template. And since we
    need to type phrase name in less places now, then change of detecting used
    phrase becomes even smaller.

    However we do track used phrases per each front-end template. If you can
    visit all website pages, then based on collected data we can safely assume,
    that all other phrases of "front-end" type are no longer in use.

    That's of course is matter of another "keep language pack up to date"
    discussion, that doesn't exist right now.

  20. c for Common is better than my b for both :-)

    right, let's dedicate another thread for lang pack maintenance ideas

    2011/9/2 Alexander Obuhovich <>