Please use the suggested format. Thanks, Saroj
On Jan 24, 2017 6:26 AM, "Philippe Verdy" <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]>: >> >>> 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 <[email protected]>: >>> >>>> 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 < >>>> [email protected]>: >>>> >>>>> 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 < >>>>> [email protected]> 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 >>>>>> [email protected]https://lists.wikimedia.org/mailman/listinfo/translators-l >>>>>> >>>>>> _______________________________________________ >>>>>> Translators-l mailing >>>>>> [email protected]https://lists.wikimedia.org/mailman/listinfo/translators-l >>>>>> >>>>>> _______________________________________________ Translators-l >>>>>> mailing list [email protected] >>>>>> 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 >>>>> [email protected]https://lists.wikimedia.org/mailman/listinfo/translators-l >>>>> >>>>> >>>>> _______________________________________________ >>>>> Translators-l mailing list >>>>> [email protected] >>>>> https://lists.wikimedia.org/mailman/listinfo/translators-l >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Translators-l mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/translators-l >>>> >>>> >>> >>> _______________________________________________ >>> Translators-l mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/translators-l >>> >>> >> > > _______________________________________________ > Translators-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/translators-l > >
_______________________________________________ Translators-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/translators-l
