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(a)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(a)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(a)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(a)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(a)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(a)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=pa…
>
<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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/translators-l
_______________________________________________
Translators-l mailing list
Translators-l(a)lists.wikimedia.org