Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Translation
Translation
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 28
    • Issues 28
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • TranslationTranslation
  • Issues
  • #53

You need to sign in or sign up before continuing.
Closed
Open
Created Sep 23, 2020 by Stéphane Lussier@urlisse

Frequency units frequently fail to be translated properly

On numerous occasions, the internal value of frequency units (eg: year, month) are sent for display to a template without being translated first.

One such issue may be found in CRM/Contribute/Form/Contribution/Main.php. In this case, a simple fix would usually suffice:

--- a/civicrm/CRM/Contribute/Form/Contribution/Main.php
+++ b/civicrm/CRM/Contribute/Form/Contribution/Main.php
@@ -548,7 +548,7 @@ class CRM_Contribute_Form_Contribution_Main extends CRM_Contribute_Form_Contribu
       if (!empty($form->_values['is_recur_interval']) || $className == 'CRM_Contribute_Form_Contribution') {
         $unit .= "(s)";
       }
-      $form->assign('frequency_unit', $unit);
+      $form->assign('frequency_unit', ts($unit));
     }
     else {
       $form->assign('one_frequency_unit', FALSE);

However, this patch in incomplete. There are multiple cases where a similar fix would need to be applied.

It's also not uncommon to find singular/plural tests in existing templates. The following example comes from templates/CRM/Contribute/Form/Contribution/ThankYou.tpl:

{if $frequency_interval > 1}
  <strong>{ts 1=$frequency_interval 2=$frequency_unit}This membership will be renewed automatically every %1 %2(s).{/ts}</strong>
{else}
  <strong>{ts 1=$frequency_unit}This membership will be renewed automatically every %1.{/ts}</strong>
{/if}

This solution looks a bit strange to me... It assumes that adding an (s) to an internal keyword will make it plural. That may work in most situations, but it would prevent the already translated keyword to be altered upon the phrase translation.

Shouldn't the keyword be fully translated and pluralized (if necessary) before being sent to the translation string?

Could the ts function take care of translating and pluralizing substrings?

I don't mean to make a huge issue out of a small one, but I wonder: Is there a pattern that we can agree on for these sorts of situations?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None