Skip to content
Thirdlane

Translation Maps

Translation Maps bridge the gap between the friendly values you enter in Configuration Manager and the raw, vendor-specific values a given phone actually expects in its config file. Different manufacturers encode the same concept differently - a time zone, for example, is -5 on a Yealink but -18000 on a Polycom - so a Translation Map lets you store one human-readable value once and have it automatically converted to the correct format for each phone model at provisioning time. This keeps your data clean and portable across mixed-vendor fleets instead of forcing you to remember each vendor’s codes.

Translation Maps are used in Device Provisioning, and allow you to specify how any provisioning related values entered by you will be translated to internal values for specific Phone Models. You can include these in the template files as needed.

For example - in your template you can define a custom variable AREA_CODE, and define translations from user-friendly names like “Palo Alto” and “San Francisco” to 650 and 415 respectively.

You can also specify how a user selected time zones will be translated into device manufacturer’s timezone formats to replace TL_TIMEZONE variable in provisioning template files. For example, US Eastern Time Zone EST5EDT translates to -5 for Yealink phones, and to -18000 for Polycom.

Create/Edit Translation Map

Translation Map Name. Unique name you would like to give to a Translation Map

Template Variables Translation Map. A map that defines how the Original Value gets replaced with Replace With value during provisioning

Time Zone Translation Map. A map that is used to translate standard Unix time zone values to the Phone Manufacturer’s Time zone. Note that you have to specify a translation for the Default Time Zone when creating a Translation Map.

Best practices

  • Create one map per vendor format. Because time zone and value encodings differ by manufacturer, a Yealink map and a Polycom map should be separate, each referenced by the matching Phone Models.
  • Always define the Default Time Zone entry. It is required, and it is the fallback used when a phone’s specific zone isn’t mapped - leaving it out can leave phones with the wrong time.
  • Keep left-hand values human-friendly and stable. Use readable inputs (city names, standard Unix zone strings) so the same value flows cleanly across models; change the vendor-specific right-hand side, not the input.
  • Extend, don’t duplicate. Add new rows to an existing map as you adopt new zones or values rather than creating near-identical maps.