Moses-support Digest, Vol 103, Issue 68

Send Moses-support mailing list submissions to
moses-support@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu

You can reach the person managing the list at
moses-support-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."


Today's Topics:

1. CFP: MT Summit XV Workshop on Patent and Scientific
Literature Translation (PSLT 2015) (Takashi Tsunakawa)
2. Re: New source formatter & checker (Hieu Hoang)


----------------------------------------------------------------------

Message: 1
Date: Wed, 27 May 2015 20:11:56 +0900
From: Takashi Tsunakawa <tuna@inf.shizuoka.ac.jp>
Subject: [Moses-support] CFP: MT Summit XV Workshop on Patent and
Scientific Literature Translation (PSLT 2015)
To: moses-support@mit.edu
Message-ID: <5565A67C.9070403@inf.shizuoka.ac.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed

Dear Moses-support ML members,

I introduce the 1st Call for Papers of The 6th Workshop on Patent and
Scientific Literature Translation (PSLT 2015) held at MT Summit XV.

[Apologize for multiple copies]

-----------------------------------------------------------------------------------------------
Call for Papers:
The 6th Workshop on Patent and Scientific Literature Translation (PSLT 2015)
-----------------------------------------------------------------------------------------------

Following the success of MT Summit 2005, 2007, 2009, 2011, and 2013
Workshops on Patent Translation, we are organizing the 6th Workshop on
Patent and Scientific Literature Translation (PSLT 2015) as a part of MT
Summit 2015 in Miami, Florida, USA. While patent information is still
one of the major application areas of machine translation, the need for
translation of different kinds of scientific literature has also been
increasing rapidly. This edition extends the area of interest to
translation of scientific literature including patents, scientific
articles, and technical reports, which have common characteristics as
well as their own characteristics. The workshop, which consists of
invited talks, presentation of submitted papers, and free discussion
like the previous editions, will be an opportunity for researchers and
practitioners to get together and exchange their ideas and experiences.

We solicit original research papers as well as survey papers and user
reports. Topics of interests include but not limited to:

* Machine translation of patents and scientific literature
* Domain adaptation of MT systems
* Translation aids for patents and scientific literature
* Language resources for patent and scientific literature translation
* Evaluation techniques for patent and scientific literature translation
* Controlled languages and machine translation
* Multilingual retrieval and classification of patents and scientific
literature

--------------------
Important Dates
--------------------
* August 10: Paper submission deadline
* August 24: Notifications to authors
* September 7: Camera-ready versions due
* October 30: Workshop

------------------------------
Submission Instructions
------------------------------
The format for papers is the same as for regular MT Summit 2015
submissions. Papers must not exceed 12 (twelve) pages plus 4 (four)
pages for references. All papers should follow the formatting
instructions included with the style files, and should be submitted in
PDF. Latex, PDF and MS Word style files are available at
http://www.amtaweb.org/mt-summit-xv-mt-researchers-call-for-papers/. To
allow for blind reviewing, please do not include author names and
affiliations within the paper and avoid obvious self-references.

Papers must be submitted to the START system
(https://www.softconf.com/mtsummit-xv/PSLT-2015/) by 11:59 pm PDT (GMT?7
hours), Monday August 10, 2015.

-----------------------------
Workshop Organization
-----------------------------
PC Co-Chairs:
Hiroyuki Kaji (Shizuoka University, Japan)
Katsuhito Sudoh (NTT, Japan)

PC Members:
TBA

Publications Chair:
Takashi Tsunakawa (Shizuoka University, Japan)

Workshop Web-site:
http://www.aamtjapio.com/pslt2015



--
Takashi Tsunakawa

Kaji Laboratory,
College of Informatics, Shizuoka University

tuna@inf.shizuoka.ac.jp






------------------------------

Message: 2
Date: Wed, 27 May 2015 18:58:06 +0400
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] New source formatter & checker
To: Jeroen Vermeulen <jtv@precisiontranslationtools.com>,
ugermann@inf.ed.ac.uk, Ulrich Germann <ulrich.germann@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID: <5565DB7E.8050607@gmail.com>
Content-Type: text/plain; charset="utf-8"

seems like referendums are all the rage at the moment so we're gonna
have 1 to decide coding style.
https://www.surveymonkey.com/s/BN38LBQ
If you work with the Moses code, please vote. This will give us a clear
mandate for future development.

Polls will open until Sunday evening. All results are public

On 27/05/2015 05:16, Jeroen Vermeulen wrote:
> On May 27, 2015 2:47:02 AM GMT+07:00, Ulrich Germann
> <ulrich.germann@gmail.com> wrote:
>
> Well, the second document does indeed give some darn good
> arguments for
> trailing braces: 1. "
> as shown to us by the prophets Kernighan and Ritchie
> "; 2. "
> K&R are _right_ and [...] K&R are right
> "; 3. "
> think 25-line terminal screens here
> "
>
> The document also has other great suggestions that we may want to
> adopt."
> Tabs are 8 characters, and thus indentations are also 8 characters
> "
>
> The fact is: with trailing braces and steadfast refusal to use
> vertical space to improve
> code readibility, you do need a tab width of 8 or so to be able to
> recognize code blocks.
>
> Incidentally, there's actually one recommendation in that document
> that IS worth
> adopting *(and in which pretty much all style guides agree
> plus-minus 5 characters or so):*
>
> The limit on the length of lines is 80 columns and this is a
> strongly preferred limit.
>
> Let me repeat that:
>
> The limit on the length of lines is 80 columns and this is a
> strongly preferred limit.
>
> And again:
>
> The limit on the length of lines is 80 columns and this is a
> strongly preferred limit.
>
> That is the only thing worth really considering from that document.
>
> We can safely consider the 25-line limit a thing of the past
> unless you program on
> your mobile phone. However, there is a good justification for the
> 80-column
> limit: merging code, where it's useful to see the code side by
> side. When
> resolving merge conflicts in git, we are usually dealing with 3
> versions that need
> to be compared. Those three columns won't fit on my screen when
> lines are 120+
> characters long.
>
> I digress. Back to the braces issue. Unlike the arguments for
> trailing braces
> (K&R did it in a printed book to save paper; I'm a retro
> programmer who likes to
> do things old school; it obscures my code so people will think I'm
> really awesome
> because they can't really understand what I'm doing without lots
> of effort, just like
> Derrida and Piaget didn't write to be understood --- they wrote
> NOT to be understood),
> so unlike these arguments, there are very good arguments for
> having opening braces
> on a new line and vertically aligned with the closing bracket.
>
> 1. It's much easier to recognize logical code blocks. It is. Try
> it out. Read code that you
> haven't written and be honest with yourself. It may seem
> unfamiliar at first, but once
> you are used to it, there's no turning back.
>
> 2. If you want to temporarily disable a condition (e.g. in
> debugging), you just comment
> out the if statement. You do not have to THEN put an opening
> brace at the beginning
> of the line (extra editing) and remove it later (extra editing
> again) --- which also
> FORCES you to be inconsistent. (You can't always remove the
> braces because
> of variable scoping). You have the same issue when you want to
> use preprocessor
> commands to have conditions only under certain circumstances,
> so instead of
> #ifdef ENABLE_CONDITION
> if (condition)
>

Tweet