Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel

On This Page:

Table of Contents
minLevel2

Before you Start.

Things you should be aware of before starting Revive Adserver development.

 


Historical Terms

Revive Adserver, as a project, has been around for a very long time, and as a result, some of the language that you will find used the code base will often not align with the language used in the UI, as the terms used in online advertising have changed over the decades.

The following is list of historical terms that may be helpful to be aware of when reading code/comments in code.

Current UI TerminologyPrevious Terminology In Code
Delivery OptionsACLs
Delivery Rules

Delivery Limitations

Limitations

Delivery Rule Sets

Targeting Channels

Channels

Coding Best Practices

Delivery Engine

When writing code that is executed as part of the process of delivering banners, it is important that warnings etc. that may be thrown by code are not displayed as output, as it is obviously not desirable to display these in the browser when displaying a banner. (Displaying warnings in the Revive Adserver UI is not ideal, but at least it will help users know what the problem is. Showing warnings about problems instead of a banner is very bad.)

Accordingly, if methods/functions called in delivery engine code could throw warnings etc., these should be suppressed / handled as appropriate, to ensure that they are not displayed to the UI.

Managing Localization

The translation of localization strings for the user interface are managed through the Revive Adserver Crowdin project.

This means that if you think a translation used in the user interface for any language other than English is incorrect, please create an account with Crowdin, and suggest a new translation there. Accepted translations are periodically merged by the core Revive Adserver team into the master branch of Revive Adserver, and will be included in the next release.

However, if you think that:

  • A master English translation needs to be changed (e.g. to reflect changed functionality);
  • A new master English translation key needs to be added (e.g. to reflect new functionality); or
  • A master English translation key needs to be removed (e.g. to reflect removed functionality)

then these changes should all be performed as a change in the master branch.

The changes to the master English files are automatically imported into the Crowdin project. Translations in languages other English will be automatically updated to reflect the added or out of date translations that need to be corrected, and to remove any keys no longer required.

Tip

Apart from translations for plugins, all translation files for Revive Adserver can be found in the directories under lib/max/language.

 

Note

Updating the master English translations for plugins is a little more complex than just editing a text file - please see the page on Plugin Translations for details on how to do this.

Once the master English translations in a plugin are updated, though, the changes are still automatically imported into Crowdin for translation into other languages.

Translation Strings in PHP Code

In PHP code, to obtain a correctly translated string for display to a user, based on their settings, use the OX_Translation class:

Code Block
require_once RV_PATH . '/lib/OX/Translation.php';
$oTranslation = new OX_Translation();
$text = $oTranslation->translate('TargetString');

Translation Strings in Smarty Templates

In Smarty template code, to obtain a correctly translated string for display to a user, based on their settings, use the t function:

Code Block
{t str=TargetString}
Note

The translation key used in the examples excludes the "str" prefix used in the translation files. That is, in both casesthe PHP and Smarty Template examples opposite, the code would be for the following entry in the translation files:

Code Block
$GLOBALS['strTargetString'] = "Target String";

Numeric, Date, and Time

and Currency

Formats in Code

TBAIn Revive Adserver, there are no options for users to define how they want number, date, and time values to be formatted. Instead, the formats for all of these are based on the language selected.

To format numbers, use the OA_Admin_NumberFormat class:

Code Block
require_once RV_PATH . '/lib/OA/Admin/NumberFormat.php';
$number = 12345.12;
$formattedNumber = OA_Admin_NumberFormat::formatNumber($number);

To format dates and times, the strings defined in the default.lang.php file should be used. For example, from the English translation file:

Code Block
// Date & time configuration
$GLOBALS['date_format'] = "%d-%m-%Y";
$GLOBALS['time_format'] = "%H:%M:%S";
$GLOBALS['minute_format'] = "%H:%M";
$GLOBALS['month_format'] = "%m-%Y";
$GLOBALS['day_format'] = "%d-%m";
$GLOBALS['week_format'] = "%W-%Y";
$GLOBALS['weekiso_format'] = "%V-%G";

These strings should be used to format dates and times as appropriate. For example:

Code Block
// Creating a formatted string (date only) from a PEAR::Date object
require_once RV_PATH . '/lib/pear/Date.php';
$oNewDate = new Date();
$formattedDate = $oNewDate->format($date_format);