When TimelineJS formats dates, it normally marks "negative years" (less than zero) with the suffix "BCE", which stands for "Before the Christian Era". This is shown in the body of each slide when the date is formatted:
and in the timenav:
This is controlled by Timeline's translation files. (This feature was not configurable in Timeline version 2, so language-appropriate translations for this feature are limited — we welcome your contributions!)
It may seem complicated, but we've found that different languages have different conventions for where to put the modifier, and even in English, it's not unheard of for people to put the modifier as a prefix. To put it simply, when TimelineJS formats a date, it sees if the year of the date is negative or positive. Then it sees if there are
suffix values configured. (It's technically possible to use both.) If the year is negative and either of those are configured for negative years, then TimelineJS converts the year to a positive value before applying the modifiers.
Making the change
If you want to change those labels (from "BCE" to "BC", or to add "AD" before or after dates with positive years), you must make a copy of the base translation file you want to use, edit those values, and configure TimelineJS to use your new file. Similarly, if you just don't want those labels at all, you can copy the translation file and make sure that all the labels are set to
Now comes the question of telling TimelineJS to use your alternative configuration. Typically, the language of a timeline is configured using a two-character language code for the
lang option, as highlighted in this example URL:
To override this for a language configuration which isn't directly supported by Knight Lab, you just replace the two-character language code with a URL which TimelineJS can use to load your alternate configuration. (Explaining what it means to put your configuration on a web server and find the URL for it is outside the scope of this document.) You also need to configure the server where you put the new language file to accept "cross-origin" requests from cdn.knightlab.com. (See below for more technical information on this detail.)
This example shows what a TimelineJS URL looks like when the language configuration is retrieved from a URL. In this case, it uses TimelineJS's German translation, which you'd normally do just by specifying 'de'.
Hopefully this helps those of you who need this know how to proceed. We welcome questions and comments below, but if we seem to not be noticing, send us a support ticket. We haven't yet figured out how to get notification of activity here.
Tech Note: Cross-origin requests
When TimelineJS gets to handling language configuration, it asks your web browser to retrieve the new JSON configuration file you've created. If the configuration file is served from a different server than the page where the Timeline is, you will run into CORS (cross-origin resource sharing) problems. Note that if you are using an iframe embed, then cross-origin is from cdn.knightlab.com to the server with the JSON file -- it doesn't help that the page which includes the timeline embed is on the same server as the JSON file.
If you have administrative control of the server where your JSON file is, you can configure it to send the
Access-Control-Allow-Origin header with a value of either
cdn.knightlab.com (assuming you're using our standard embed), or whatever other server, or
* if you prefer to indicate that pages from any server can make cross-origin requests to yours. Further discussion of this topic is more than belongs in this article.
One way to avoid the "cross-origin problem" is to install a copy of the TimelineJS source code on your own server. Technically, this is easy for people who are familiar with configuring web servers. You can download the code from https://cdn.knightlab.com/libs/timeline3/latest/timeline3.zip and install it on your server, just by unzipping the archive. Of course, then if we make future changes to TimelineJS, you'd have to make a point of going and downloading them and updating your installation.
If you do this, then you could put your new language file anywhere on the same server, and there would be no cross-origin issue.