The matter at hand originates as follows:

• Using strings of code to substitute manual entry of dates by translators while translating the Tech News on Meta was proposed. For Arabic, I proposed using two versions of Gregorian month names commonly used in Arab countries in Arabic script instead of using one only. Further details may be found at this page https://en.wikipedia.org/wiki/Arabic_names_of_calendar_months.
• When I translate month names of Gregorian calendar, I use the name used in Egypt, Sudan and Persian Gulf countries followed by the name used in the Levant and Mesopotamia, separated by a slash "/". As I mentioned in my email exchange with mathieu stumpf guntz, the proposition was to use both to cater for this duality, instead of favouring one usage over the other.
• My understanding for the string of code used is that it recalls values stored already, so I think that to have my proposition possible, the code will remain the same without change, while the change will affect the values stored for month names. An example is as follows:

If the {{#time:$defualtformat|$date1|$format_language_code}} is used, it will display in Arabic the date followed by the name of the month in Arabic (i.e. 00 Yanāyir) [this is a transliteration of January]. If the stored values for month names were to change as I use them, it will show as follows (00 Yanāyir/Kānūn ath-Thānī). If this true, I think that this longer string of text would cause size issues if the values were used inside a table.

As you can see, Yanāyir/Kānūn are one unit without spaces, which might affect text alignment in the table and would render a table bigger than the source table.

I'm not sure to understand your concern. The value is generated for the given parameters in the context where it appears. So if there are other context with tables where you would like to use this function, you can always adapt it, can't you? There is no table in the Technews related message.

My concern is not limited to Tech News, since such function/string of code can be used in any page on Meta or even other wikis.

@Haythamabulela , but what would prevent editors to adapt formatting for each use case? The function can be in fact already be used for generating many output on any page on Meta. Adding more supported calendar won't change anything regarding this, it will just offer ability to provide more formatted output, but each function call have to provide parameters to indicate which format should be generated.

Maybe there is a confusion with the goal behind its use in the Technews translation process. Here the goal is to avoid translator having to edit manually a message where only dates are varying between issues. So we put this dates in translation variables, the translator make the work once, and next issues will provide a 100% match with the previous translation, because all the varying part is confined in a variable which is automatically formatted as specified in the first translation. That doesn't mean that any other function call anywhere on the same wiki will be affected by this format specification. I hope this explanation makes things more clear for you, if it wasn't already. Please tell me if it is clear for you, and if it seems fine.

@Psychoslave I think my lack of knowledge of coding and its terms will make this confusion hard to clear.

Let's try another approach. Values recalled by this proposed string of code are saved somewhere - perhaps MediaWiki software - under the language code assigned for Arabic. If the values listed there for month names were updated [to be ?Yanayir/Kanun al-Thani instead of Yanayir only], my proposition will be fulfilled. No additional calendars are required, since the same Arabic calendar will display both names as one value in this manner.