Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson --
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Hi,
I think searching the right format to have then automation when you translate 50 newsletters a year is really worth it.
Please include this!
Regards,
Sylvain Chiron
Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j 日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
But ‘defualtformat’ looks a bit wrong (it is already online).
Sylvain
Le 19/01/2017 à 20:17, Sylvain Chiron a écrit :
Hi,
I think searching the right format to have then automation when you translate 50 newsletters a year is really worth it.
Please include this!
Regards,
Sylvain Chiron
Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j 日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Saluton Sylvain,
Do you mean it should be "defaultformat" (with "au" rather than "ua") or "default_format", or something else?
Le 19/01/2017 à 20:20, Sylvain Chiron a écrit :
But ‘defualtformat’ looks a bit wrong (it is already online).
Sylvain
Le 19/01/2017 à 20:17, Sylvain Chiron a écrit :
Hi,
I think searching the right format to have then automation when you translate 50 newsletters a year is really worth it.
Please include this!
Regards,
Sylvain Chiron
Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j 日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
On Thu, Jan 19, 2017 at 6:58 PM, Haytham Aly haytham.hammam@gmail.com wrote:
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Hi Haytham,
Whereas I could be mistaken, I don't think there's a good way to automate both, I'm afraid. At least not that I'm aware of.
//Johan Jönsson --
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "/aii/" (Assyrian Neo-Aramaic) or /"arc/" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names.
So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii||}} ({{#time:F|$date1|aii||}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop.
Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
So, here is a corresponding task: https://phabricator.wikimedia.org/T155824
Le 20/01/2017 à 11:25, mathieu stumpf guntz a écrit :
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "/aii/" (Assyrian Neo-Aramaic) or /"arc/" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names.
So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii||}} ({{#time:F|$date1|aii||}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop.
Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=pag...
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "*aii*" (Assyrian Neo-Aramaic) or *"arc*" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii}} ({{#time:F|$date1|aii}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</
|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means
that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special: Translate&group=page-Tech%2FNews%2F2017%2F04&action=page
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names?
Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)?
I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket https://phabricator.wikimedia.org/T155824.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz <psychoslave@culture-libre.org mailto:psychoslave@culture-libre.org> wrote:
Saluton Haytham, If you look at the documentation <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time>, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar <https://en.wikipedia.org/wiki/Assyrian_calendar> is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "/aii/" (Assyrian Neo-Aramaic) or /"arc/" (Aramaic language), but in both case it seems that localization is missing <https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro> for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use: {{#time:xaF|$date1|aii||}} ({{#time:F|$date1|aii||}}) Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan, This idea is brilliant. My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice. Regards, Haytham Abulela Aly Freelance Translator Creative Translation "Creative & Confident" Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone, TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this? Longer version: Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week. It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}. For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari". Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example. All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time> Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week. Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language. The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide. https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page <https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page> https://meta.wikimedia.org/wiki/Tech/News/2017/04 <https://meta.wikimedia.org/wiki/Tech/News/2017/04> //Johan Jönsson -- _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
-- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx Arab Professional Translators' Society certified member (#10850) http://www.arabtranslators.org/Certification/certified_members_801_900.aspx Certified member at Egyptian Translators Association (EGYTA) http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn Profile on LinkedIn http://ca.linkedin.com/in/haythamhammam Profile on ProZ.com http://www.proz.com/translator/895138 Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz < psychoslave@culture-libre.org>:
Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names?
Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)?
I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket https://phabricator.wikimedia.org/T155824.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "*aii*" (Assyrian Neo-Aramaic) or *"arc*" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii}} ({{#time:F|$date1|aii}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</
|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means
that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Transla te&group=page-Tech%2FNews%2F2017%2F04&action=page
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/ma ilman/listinfo/translators-l
-- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx Arab Professional Translators' Society certified member (#10850) http://www.arabtranslators.org/Certification/certified_members_801_900.aspx Certified member at Egyptian Translators Association (EGYTA) http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn Profile on LinkedIn http://ca.linkedin.com/in/haythamhammam Profile on ProZ.com http://www.proz.com/translator/895138 Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
There'a absolutely no need of non-breaking spaces in French dates ! The numeric format "dd/mm/yyyy" has no space at all. The long format "dd monthname yyyy" uses standard spaces for word separation (they are breakable). And there's NEVER any space in the middel of the year.
However the French non-breaking spaces are need for punctuations (before "!", "?", ":" or in the middle of « guillemets » (standard French quotation marks) or in numbers as group separators. These should ideally be narrower than standard spaces (i.e. NNBSP U+203F rather than NBSP U+00A0). But none of these occur in French dates.
2017-01-23 19:09 GMT+01:00 Pols12 poltron54@gmail.com:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz < psychoslave@culture-libre.org>:
Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names?
Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)?
I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket https://phabricator.wikimedia.org/T155824.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "*aii*" (Assyrian Neo-Aramaic) or *"arc*" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii}} ({{#time:F|$date1|aii}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</
|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which
means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Transla te&group=page-Tech%2FNews%2F2017%2F04&action=page
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/ma ilman/listinfo/translators-l
-- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx Arab Professional Translators' Society certified member (#10850) http://www.arabtranslators.org/Certification/certified_members_801_900.aspx Certified member at Egyptian Translators Association (EGYTA) http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn Profile on LinkedIn http://ca.linkedin.com/in/haythamhammam Profile on ProZ.com http://www.proz.com/translator/895138 Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
According to w:fr:WP:TYPO https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#NON_C.C3.89SURE_NOMBRE_NOM, we should use non-breakable spaces in French long format dates.
2017-01-23 19:36 GMT+01:00 Philippe Verdy verdy_p@wanadoo.fr:
There'a absolutely no need of non-breaking spaces in French dates ! The numeric format "dd/mm/yyyy" has no space at all. The long format "dd monthname yyyy" uses standard spaces for word separation (they are breakable). And there's NEVER any space in the middel of the year.
However the French non-breaking spaces are need for punctuations (before "!", "?", ":" or in the middle of « guillemets » (standard French quotation marks) or in numbers as group separators. These should ideally be narrower than standard spaces (i.e. NNBSP U+203F rather than NBSP U+00A0). But none of these occur in French dates.
2017-01-23 19:09 GMT+01:00 Pols12 poltron54@gmail.com:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz < psychoslave@culture-libre.org>:
Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names?
Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)?
I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket https://phabricator.wikimedia.org/T155824.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "*aii*" (Assyrian Neo-Aramaic) or *"arc*" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii}} ({{#time:F|$date1|aii}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</
|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which
means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Transla te&group=page-Tech%2FNews%2F2017%2F04&action=page
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/ma ilman/listinfo/translators-l
-- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx Arab Professional Translators' Society certified member (#10850) http://www.arabtranslators.org/Certification/certified_members_801_900.aspx Certified member at Egyptian Translators Association (EGYTA) http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn Profile on LinkedIn http://ca.linkedin.com/in/haythamhammam Profile on ProZ.com http://www.proz.com/translator/895138 Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Ok between a quantity number (provided it is a short integer) and the following noun or unit (unconditional non-breaking before abbreviated units such as "m" or "kg"), but between a mouth day number and a month or a month and a year, there's no such restriction and the space is perfectly breakable (there's no quantity-unit relation between these numbers that are just enumerated in order).
It is just suggested, in wide enough paragraphs, to avoid breaking dates, but the same could also be said about peole names (first name, last name) or toponyms: this is a styling refinement when typesetting documents, but actually this only applies if you can predeict the paragraph width and the unbreakable part is narrow compared to the paragraph, and probably only implemented when using justified paragraphs and other whitespaces can be expanded.
This "rule" on dates is then definitely not a rule but a matter of preferences, and only applicable to typesetted documents, when you know the fonts used, their sizes, the paragraph width, and the kind of text justification made (or microjustifications, including kerning and variable floatting) around complex non-recangular shapes.
If you have a table containing dates, non-breaking spaces will be worse as it will force other columns to become narrower or to have overlapping columns. long dates are perfectly breakable in that case I can see lot of examples of printed books where long dates in paragraphs are broken by linewraps because these are clearly separate words in an enumeration (it does not matter if the day number or year is spelled completely or written with digits, or if there's a weekday name prepended or time appended). Only dates in short format (dd/mm/yyyy) are unbreakable.
2017-01-24 1:11 GMT+01:00 Pols12 poltron54@gmail.com:
According to w:fr:WP:TYPO https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#NON_C.C3.89SURE_NOMBRE_NOM, we should use non-breakable spaces in French long format dates.
2017-01-23 19:36 GMT+01:00 Philippe Verdy verdy_p@wanadoo.fr:
There'a absolutely no need of non-breaking spaces in French dates ! The numeric format "dd/mm/yyyy" has no space at all. The long format "dd monthname yyyy" uses standard spaces for word separation (they are breakable). And there's NEVER any space in the middel of the year.
However the French non-breaking spaces are need for punctuations (before "!", "?", ":" or in the middle of « guillemets » (standard French quotation marks) or in numbers as group separators. These should ideally be narrower than standard spaces (i.e. NNBSP U+203F rather than NBSP U+00A0). But none of these occur in French dates.
2017-01-23 19:09 GMT+01:00 Pols12 poltron54@gmail.com:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz < psychoslave@culture-libre.org>:
Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names?
Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)?
I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket https://phabricator.wikimedia.org/T155824.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "*aii*" (Assyrian Neo-Aramaic) or *"arc*" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii}} ({{#time:F|$date1|aii}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</
|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which
means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Transla te&group=page-Tech%2FNews%2F2017%2F04&action=page
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/ma ilman/listinfo/translators-l
-- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx Arab Professional Translators' Society certified member (#10850) http://www.arabtranslators.org/Certification/certified_members_801_900.aspx Certified member at Egyptian Translators Association (EGYTA) http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn Profile on LinkedIn http://ca.linkedin.com/in/haythamhammam Profile on ProZ.com http://www.proz.com/translator/895138 Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Please use the suggested format.
Thanks, Saroj
On Jan 24, 2017 6:26 AM, "Philippe Verdy" verdy_p@wanadoo.fr wrote:
Ok between a quantity number (provided it is a short integer) and the following noun or unit (unconditional non-breaking before abbreviated units such as "m" or "kg"), but between a mouth day number and a month or a month and a year, there's no such restriction and the space is perfectly breakable (there's no quantity-unit relation between these numbers that are just enumerated in order).
It is just suggested, in wide enough paragraphs, to avoid breaking dates, but the same could also be said about peole names (first name, last name) or toponyms: this is a styling refinement when typesetting documents, but actually this only applies if you can predeict the paragraph width and the unbreakable part is narrow compared to the paragraph, and probably only implemented when using justified paragraphs and other whitespaces can be expanded.
This "rule" on dates is then definitely not a rule but a matter of preferences, and only applicable to typesetted documents, when you know the fonts used, their sizes, the paragraph width, and the kind of text justification made (or microjustifications, including kerning and variable floatting) around complex non-recangular shapes.
If you have a table containing dates, non-breaking spaces will be worse as it will force other columns to become narrower or to have overlapping columns. long dates are perfectly breakable in that case I can see lot of examples of printed books where long dates in paragraphs are broken by linewraps because these are clearly separate words in an enumeration (it does not matter if the day number or year is spelled completely or written with digits, or if there's a weekday name prepended or time appended). Only dates in short format (dd/mm/yyyy) are unbreakable.
2017-01-24 1:11 GMT+01:00 Pols12 poltron54@gmail.com:
According to w:fr:WP:TYPO https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#NON_C.C3.89SURE_NOMBRE_NOM, we should use non-breakable spaces in French long format dates.
2017-01-23 19:36 GMT+01:00 Philippe Verdy verdy_p@wanadoo.fr:
There'a absolutely no need of non-breaking spaces in French dates ! The numeric format "dd/mm/yyyy" has no space at all. The long format "dd monthname yyyy" uses standard spaces for word separation (they are breakable). And there's NEVER any space in the middel of the year.
However the French non-breaking spaces are need for punctuations (before "!", "?", ":" or in the middle of « guillemets » (standard French quotation marks) or in numbers as group separators. These should ideally be narrower than standard spaces (i.e. NNBSP U+203F rather than NBSP U+00A0). But none of these occur in French dates.
2017-01-23 19:09 GMT+01:00 Pols12 poltron54@gmail.com:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz < psychoslave@culture-libre.org>:
Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names?
Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)?
I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket https://phabricator.wikimedia.org/T155824.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
Saluton Haytham,
If you look at the documentation https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar https://en.wikipedia.org/wiki/Assyrian_calendar is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "*aii*" (Assyrian Neo-Aramaic) or *"arc*" (Aramaic language), but in both case it seems that localization is missing https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use:
{{#time:xaF|$date1|aii}} ({{#time:F|$date1|aii}})
Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator Creative Translation "Creative & Confident"
Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this?
Longer version:
Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week.
It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</ >|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari".
Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example.
All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week.
Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language.
The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Transla te&group=page-Tech%2FNews%2F2017%2F04&action=page
https://meta.wikimedia.org/wiki/Tech/News/2017/04
//Johan Jönsson
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
-- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx Arab Professional Translators' Society certified member (#10850) http://www.arabtranslators.org/Certification/certified_members_801_900.aspx Certified member at Egyptian Translators Association (EGYTA) http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn Profile on LinkedIn http://ca.linkedin.com/in/haythamhammam Profile on ProZ.com http://www.proz.com/translator/895138 Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.
Translators-l mailing listTranslators-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
It's really the first time ever I hear about this rule. Sure making 3 digits group separated with thin non breaking spaces is a good practice that you might use for the vintage, although to my mind that's a practice whose readability usefulness comes with larger number. That is 2017 is far more common than 2 017, and you might even argue that habit might make the former less disturbing.
Now regarding spaces between words, do anyone have an authoritative source on the subject and what it says on this topic? For example there is the Lexique des règles typographiques en usage à l'Imprimerie nationale https://fr.wikipedia.org/wiki/Lexique_des_r%C3%A8gles_typographiques_en_usage_%C3%A0_l%27Imprimerie_nationale but I have no access to it right now.
Le 24/01/2017 à 01:43, Saroj Dhakal a écrit :
Please use the suggested format.
Thanks, Saroj
On Jan 24, 2017 6:26 AM, "Philippe Verdy" <verdy_p@wanadoo.fr mailto:verdy_p@wanadoo.fr> wrote:
Ok between a quantity number (provided it is a short integer) and the following noun or unit (unconditional non-breaking before abbreviated units such as "m" or "kg"), but between a mouth day number and a month or a month and a year, there's no such restriction and the space is perfectly breakable (there's no quantity-unit relation between these numbers that are just enumerated in order). It is just suggested, in wide enough paragraphs, to avoid breaking dates, but the same could also be said about peole names (first name, last name) or toponyms: this is a styling refinement when typesetting documents, but actually this only applies if you can predeict the paragraph width and the unbreakable part is narrow compared to the paragraph, and probably only implemented when using justified paragraphs and other whitespaces can be expanded. This "rule" on dates is then definitely not a rule but a matter of preferences, and only applicable to typesetted documents, when you know the fonts used, their sizes, the paragraph width, and the kind of text justification made (or microjustifications, including kerning and variable floatting) around complex non-recangular shapes. If you have a table containing dates, non-breaking spaces will be worse as it will force other columns to become narrower or to have overlapping columns. long dates are perfectly breakable in that case I can see lot of examples of printed books where long dates in paragraphs are broken by linewraps because these are clearly separate words in an enumeration (it does not matter if the day number or year is spelled completely or written with digits, or if there's a weekday name prepended or time appended). Only dates in short format (dd/mm/yyyy) are unbreakable. 2017-01-24 1:11 GMT+01:00 Pols12 <poltron54@gmail.com <mailto:poltron54@gmail.com>>: According to w:fr:WP:TYPO <https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#NON_C.C3.89SURE_NOMBRE_NOM>, we should use non-breakable spaces in French long format dates. 2017-01-23 19:36 GMT+01:00 Philippe Verdy <verdy_p@wanadoo.fr <mailto:verdy_p@wanadoo.fr>>: There'a absolutely no need of non-breaking spaces in French dates ! The numeric format "dd/mm/yyyy" has no space at all. The long format "dd monthname yyyy" uses standard spaces for word separation (they are breakable). And there's NEVER any space in the middel of the year. However the French non-breaking spaces are need for punctuations (before "!", "?", ":" or in the middle of « guillemets » (standard French quotation marks) or in numbers as group separators. These should ideally be narrower than standard spaces (i.e. NNBSP U+203F rather than NBSP U+00A0). But none of these occur in French dates. 2017-01-23 19:09 GMT+01:00 Pols12 <poltron54@gmail.com <mailto:poltron54@gmail.com>>: According to me, it’s a real improvement. How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12 2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz <psychoslave@culture-libre.org <mailto:psychoslave@culture-libre.org>>: Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names? Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)? I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket <https://phabricator.wikimedia.org/T155824>. Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards, On 20 January 2017 at 02:25, mathieu stumpf guntz <psychoslave@culture-libre.org <mailto:psychoslave@culture-libre.org>> wrote: Saluton Haytham, If you look at the documentation <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time>, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar <https://en.wikipedia.org/wiki/Assyrian_calendar> is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "/aii/" (Assyrian Neo-Aramaic) or /"arc/" (Aramaic language), but in both case it seems that localization is missing <https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro> for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use: {{#time:xaF|$date1|aii||}} ({{#time:F|$date1|aii||}}) Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan, This idea is brilliant. My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice. Regards, Haytham Abulela Aly Freelance Translator Creative Translation "Creative & Confident" Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone, TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this? Longer version: Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week. It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}. For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari". Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example. All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time> Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week. Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language. The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide. https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page <https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page> https://meta.wikimedia.org/wiki/Tech/News/2017/04 <https://meta.wikimedia.org/wiki/Tech/News/2017/04> //Johan Jönsson -- _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> -- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) <http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx> Arab Professional Translators' Society certified member (#10850) <http://www.arabtranslators.org/Certification/certified_members_801_900.aspx> Certified member at Egyptian Translators Association (EGYTA) <http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn> Profile on LinkedIn <http://ca.linkedin.com/in/haythamhammam> Profile on ProZ.com <http://www.proz.com/translator/895138> Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy. _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Ok, here is more explanation on the topic https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#Nombres_et_espaces. Which means you might use something like:
{{#time:j F|| |{{formatnum:|Y}}|$date1|$format_language_code}}
Le 24/01/2017 à 09:55, mathieu stumpf guntz a écrit :
It's really the first time ever I hear about this rule. Sure making 3 digits group separated with thin non breaking spaces is a good practice that you might use for the vintage, although to my mind that's a practice whose readability usefulness comes with larger number. That is 2017 is far more common than 2 017, and you might even argue that habit might make the former less disturbing.
Now regarding spaces between words, do anyone have an authoritative source on the subject and what it says on this topic? For example there is the Lexique des règles typographiques en usage à l'Imprimerie nationale https://fr.wikipedia.org/wiki/Lexique_des_r%C3%A8gles_typographiques_en_usage_%C3%A0_l%27Imprimerie_nationale but I have no access to it right now.
Le 24/01/2017 à 01:43, Saroj Dhakal a écrit :
Please use the suggested format.
Thanks, Saroj
On Jan 24, 2017 6:26 AM, "Philippe Verdy" <verdy_p@wanadoo.fr mailto:verdy_p@wanadoo.fr> wrote:
Ok between a quantity number (provided it is a short integer) and the following noun or unit (unconditional non-breaking before abbreviated units such as "m" or "kg"), but between a mouth day number and a month or a month and a year, there's no such restriction and the space is perfectly breakable (there's no quantity-unit relation between these numbers that are just enumerated in order). It is just suggested, in wide enough paragraphs, to avoid breaking dates, but the same could also be said about peole names (first name, last name) or toponyms: this is a styling refinement when typesetting documents, but actually this only applies if you can predeict the paragraph width and the unbreakable part is narrow compared to the paragraph, and probably only implemented when using justified paragraphs and other whitespaces can be expanded. This "rule" on dates is then definitely not a rule but a matter of preferences, and only applicable to typesetted documents, when you know the fonts used, their sizes, the paragraph width, and the kind of text justification made (or microjustifications, including kerning and variable floatting) around complex non-recangular shapes. If you have a table containing dates, non-breaking spaces will be worse as it will force other columns to become narrower or to have overlapping columns. long dates are perfectly breakable in that case I can see lot of examples of printed books where long dates in paragraphs are broken by linewraps because these are clearly separate words in an enumeration (it does not matter if the day number or year is spelled completely or written with digits, or if there's a weekday name prepended or time appended). Only dates in short format (dd/mm/yyyy) are unbreakable. 2017-01-24 1:11 GMT+01:00 Pols12 <poltron54@gmail.com <mailto:poltron54@gmail.com>>: According to w:fr:WP:TYPO <https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#NON_C.C3.89SURE_NOMBRE_NOM>, we should use non-breakable spaces in French long format dates. 2017-01-23 19:36 GMT+01:00 Philippe Verdy <verdy_p@wanadoo.fr <mailto:verdy_p@wanadoo.fr>>: There'a absolutely no need of non-breaking spaces in French dates ! The numeric format "dd/mm/yyyy" has no space at all. The long format "dd monthname yyyy" uses standard spaces for word separation (they are breakable). And there's NEVER any space in the middel of the year. However the French non-breaking spaces are need for punctuations (before "!", "?", ":" or in the middle of « guillemets » (standard French quotation marks) or in numbers as group separators. These should ideally be narrower than standard spaces (i.e. NNBSP U+203F rather than NBSP U+00A0). But none of these occur in French dates. 2017-01-23 19:09 GMT+01:00 Pols12 <poltron54@gmail.com <mailto:poltron54@gmail.com>>: According to me, it’s a real improvement. How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12 2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz <psychoslave@culture-libre.org <mailto:psychoslave@culture-libre.org>>: Well, I don't have much knowledge about calendar living practices beyond Greogorian calendar, sorry if I misunderstood your problem. Does that also apply to day names, or just month names? Would you be kind enough to give me some concrete examples of what you would like to obtain and what are possible side effect you are concern about, with some explanation and latin transcription (if possible)? I still believe adding other calendar support might have some interest. But maybe it would be more relevant to continue this aspect of the discussion on the phabricator ticket <https://phabricator.wikimedia.org/T155824>. Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu, My comment is not related to Assyrian or Aramaic. The issue is that countries of the Levant and Mesopotamia have applied the names of the Assyrian/Aramaic calendar to the Gregorian calendar in Arabic letters. This has become a norm for decades. I think that all that needs to be done in this regard is to update the list from which the string of code suggested retrieves values, and the string of code shall remain as is without any changes necessary. My concern here would be that this might affect values in cells of tables, since the string of text will comprise of two or three words. If this matter becomes a nuisance, we may ignore it as the current state of affairs is suitable for the majority of Arabic speakers. I was trying to have an inclusive approach instead of favouring one format over another. Regards, On 20 January 2017 at 02:25, mathieu stumpf guntz <psychoslave@culture-libre.org <mailto:psychoslave@culture-libre.org>> wrote: Saluton Haytham, If you look at the documentation <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time>, non-Gregorian formating is supported. Now having a deeper look at it, it seems that Assyrian calendar <https://en.wikipedia.org/wiki/Assyrian_calendar> is not yet in the set of supported calendars, so a phabricator ticket should be filled here I think, shouldn't it. I don't know what is the the ISO 639-3 you would like to use "/aii/" (Assyrian Neo-Aramaic) or /"arc/" (Aramaic language), but in both case it seems that localization is missing <https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro> for already provided month names. So for the sake of the example, let's say there was a "xaF" formatting code which would provide an Assyrian calendar full month name, then as far as I understand, you would like to use: {{#time:xaF|$date1|aii||}} ({{#time:F|$date1|aii||}}) Thank you Johan for the feedback request. We have here and there complaints when staff is argued to not take enough into account community advises, so it seems fair to also emphasize actions when they are done with a community feedback in the loop. Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan, This idea is brilliant. My own concern for Arabic is that there are two major ways for displaying Gregorian month names; transliteration as well as the Assyrian names. Usually transliterated names suffice, but I prefer using both divided by a slash. This is due to differences in official use, since transliterated names are used in Egypt, Sudan, Libya, Yemen, and Gulf states; while Assyrian names are used in Iraq, Syria, Lebanon, Jordan and Palestine. Could this automation function render both or just the common transliterated month names? It would be a bonus to have both displayed, though only transliterated month names would suffice. Regards, Haytham Abulela Aly Freelance Translator Creative Translation "Creative & Confident" Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) Arab Professional Translators' Society member (#10850) Certified member at Egyptian Translators Association (EGYTA) Registered at ProZ.com and LinkedIn.com On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone, TL;DR: Dates in items that are in the newsletter every week could be in a format that means you could get a 100% in the translation memory and not have to change the days and months every week. Do you want this? Longer version: Based on Mathieu's suggestion, I've tested adding dates within <tvar> tags. This makes it more complicated the first time you translate, but should mean that you can then use a 100% match from the translation memory every time and just click on it the same way you do for any other content that stays exactly the same, instead of manually having to change the days and months every new week. It looks like this: {#time:<tvar|defualtformat>d xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}} which means that I get this when I translate: {{#time:$defualtformat|$date1|$format_language_code}}. For Swedish, I can just keep it like that: Where the English original said "24 January" the Swedish translation will say "24 januari". Some languages write dates in another format. For Mandarin Chinese, the first time I do a translation I need to change it to {{#time:n月j日|$date1|$format_language_code}} (and the same for $date2 and $date3). I imagine RTL languages will need to change something too the first time they translate this, for example. All possible options are described here: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time> Pro: Less burden for returning translators. You translate this once, whether you change the date format or not, then you just click on the translation in the translation memory next week. Con: More complicated. More difficult for new translators, especially if the standard format doesn't match the norms of their language. The question: Do you want this, or did you prefer it the way it was? This is all about making it as easy as possible for you, so you decide. https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page <https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page> https://meta.wikimedia.org/wiki/Tech/News/2017/04 <https://meta.wikimedia.org/wiki/Tech/News/2017/04> //Johan Jönsson -- _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> -- Haytham Abulela ALY Certified member of the Society of Translators and Interpreters of British Columbia (STIBC) (EN>AR) <http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx> Arab Professional Translators' Society certified member (#10850) <http://www.arabtranslators.org/Certification/certified_members_801_900.aspx> Certified member at Egyptian Translators Association (EGYTA) <http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn> Profile on LinkedIn <http://ca.linkedin.com/in/haythamhammam> Profile on ProZ.com <http://www.proz.com/translator/895138> Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy. _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l> _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
On Tue, Jan 24, 2017 at 10:19 AM, mathieu stumpf guntz psychoslave@culture-libre.org wrote:
Ok, here is more explanation on the topic. Which means you might use something like:
{{#time:j F {{formatnum:Y}}|$date1|$format_language_code}}
One small addition: You want to use   instead of or n and s will be transformed to numbers (date of the month and seconds after the minute, respectively).
//Johan Jönsson --
Thank you Johan for the technical explanation! =)
I think Translator-l is not the place to discuss about French typography. Pols12
2017-01-24 10:32 GMT+01:00 Johan Jönsson jjonsson@wikimedia.org:
On Tue, Jan 24, 2017 at 10:19 AM, mathieu stumpf guntz psychoslave@culture-libre.org wrote:
Ok, here is more explanation on the topic. Which means you might use
something like:
{{#time:j F {{formatnum:Y}}|$date1|$format_language_code}}
One small addition: You want to use   instead of or n and s will be transformed to numbers (date of the month and seconds after the minute, respectively).
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Le 25/01/2017 à 11:46, Pols12 a écrit :
Thank you Johan for the technical explanation! =)
I think Translator-l is not the place to discuss about French typography. Pols12
I'm not sure there really is any descent place to do that ever, but French speakers do like to do it anywhere. :P
2017-01-24 10:32 GMT+01:00 Johan Jönsson <jjonsson@wikimedia.org mailto:jjonsson@wikimedia.org>:
On Tue, Jan 24, 2017 at 10:19 AM, mathieu stumpf guntz <psychoslave@culture-libre.org <mailto:psychoslave@culture-libre.org>> wrote: > > Ok, here is more explanation on the topic. Which means you might use something like: > > {{#time:j F {{formatnum:Y}}|$date1|$format_language_code}} One small addition: You want to use   instead of or n and s will be transformed to numbers (date of the month and seconds after the minute, respectively). //Johan Jönsson -- _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
On Mon, Jan 23, 2017 at 7:09 PM, Pols12 poltron54@gmail.com wrote:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
Hi!
So, not having an opinion on how the French dates should look, a general reply regarding how to change them if you want to:
If you're happy with how the dates look, you just keep {{#time:$defaultformat|$date1|$format_language_code}} (and $date2 and $date3), but if you want to change something, you just replace $defaultformat in the string. For example, to get the same thing but with a non-breaking space, you use this instead of $defaultformat: {{#time:j xg|$date1|$format_language_code}}
Help: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
The tricky thing to remember is that you need to use unicode characters if you want to write text or add things like a non-breaking space, because the function will transform the n to the number of the month and the s to seconds past the minute if you write .
//Johan Jönsson --
Will Translate extension allow to save message without all variables used?
*--* *Vira Motorko* project manager, Wikimedia Ukraine https://ua.wikimedia.org/ non-profit organisation m: +380667740499 | f: vira.motorko https://www.facebook.com/vira.motorko | w: Ата https://meta.wikimedia.org/wiki/User:Ата
Are you saving your documents in free formats? ;) Help save natural resources – please think twice before printing this e-mail or any attachments.
2017-01-24 8:44 GMT+02:00 Johan Jönsson jjonsson@wikimedia.org:
On Mon, Jan 23, 2017 at 7:09 PM, Pols12 poltron54@gmail.com wrote:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12
Hi!
So, not having an opinion on how the French dates should look, a general reply regarding how to change them if you want to:
If you're happy with how the dates look, you just keep {{#time:$defaultformat|$date1|$format_language_code}} (and $date2 and $date3), but if you want to change something, you just replace $defaultformat in the string. For example, to get the same thing but with a non-breaking space, you use this instead of $defaultformat: {{#time:j xg|$date1|$format_language_code}}
Help: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
The tricky thing to remember is that you need to use unicode characters if you want to write text or add things like a non-breaking space, because the function will transform the n to the number of the month and the s to seconds past the minute if you write .
//Johan Jönsson
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
Yes, it just warn you that you didn't to minimize probability you didn't just forget or misspelled it.
Le 24/01/2017 à 09:32, Vira Motorko a écrit :
Will Translate extension allow to save message without all variables used?
/--/ /Vira Motorko/ project manager, Wikimedia Ukraine https://ua.wikimedia.org/ non-profit organisation m: +380667740499 | f: vira.motorko https://www.facebook.com/vira.motorko | w: Ата https://meta.wikimedia.org/wiki/User:%D0%90%D1%82%D0%B0
Are you saving your documents in free formats? ;) Help save natural resources – please think twice before printing this e-mail or any attachments.
2017-01-24 8:44 GMT+02:00 Johan Jönsson <jjonsson@wikimedia.org mailto:jjonsson@wikimedia.org>:
On Mon, Jan 23, 2017 at 7:09 PM, Pols12 <poltron54@gmail.com <mailto:poltron54@gmail.com>> wrote: According to me, it’s a real improvement. How can we edit or suggest an edit to the date format? Indeed, we used to use non-breaking spaces in French dates. Pols12 Hi! So, not having an opinion on how the French dates should look, a general reply regarding how to change them if you want to: If you're happy with how the dates look, you just keep {{#time:$defaultformat|$date1|$format_language_code}} (and $date2 and $date3), but if you want to change something, you just replace $defaultformat in the string. For example, to get the same thing but with a non-breaking space, you use this instead of $defaultformat: {{#time:j xg|$date1|$format_language_code}} Help: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time <https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time> The tricky thing to remember is that you need to use unicode characters if you want to write text or add things like a non-breaking space, because the function will transform the n to the number of the month and the s to seconds past the minute if you write . //Johan Jönsson -- _______________________________________________ Translators-l mailing list Translators-l@lists.wikimedia.org <mailto:Translators-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/translators-l <https://lists.wikimedia.org/mailman/listinfo/translators-l>
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l
On Tue, Jan 24, 2017 at 9:32 AM, Vira Motorko vira.motorko@gmail.com wrote:
Will Translate extension allow to save message without all variables used?
Yes. You can also, if you prefer, completely ignore the entire {{#time:$defualtformat|$date1|$format_language_code}} thing and just write "January 24" instead, but then you'll have to retranslate it the next time, of course.
//Johan Jönsson --
translators-l@lists.wikimedia.org