This bug provides two features:
1/ when a new document is created the language is set to the current
keyboard language.
2/ when keyboard is switched at OS level, the input language of
current window is changed. The language is set preferably to one of
those of the document. Ex. if the keyboard changes to en_GB but one
is typing a document in US English and Hebrew, then US English will
be selected rather that adding UK English to the list.
The implementation depends a lot on Qt. The platform status is :
* working on Windows 10
* not working with Linux (although 1/ works with Qt4); it seems that
Qt5 supports switching through ibus, but I do not know what this
means.
* not yet tested on macOS.
This addresses bugs #6450, #6247 and somehow #10514.
It is now possible to specify in the lib/language file whether screen
rows can be broken anywhere (CJK languages) or only at work boundary.
Set WordWrap to false for the CJK languages (notice that japanese-cjk
had been forgotten before).
Moreover, remove a test for separators in row element that was not
really helpful.
Fixes part of ticket #10299.
AsBabelOptions was introduced 2010 in [cc5dd37a2a05/lyxgit].
Since the re-orgianization and opening of the Babel package to
"contributed" language definitions in March 2013, it is no longer required.
Clean up after Part 1 [1361f1a45f23/lyxgit].
With this commit, info insets leave the dark backstage room of an opaque
and quite hidden dev-only feature and come frontstage.
In the UI, they present themselves as "Fields" since this is what people
know from word processors. Other user-related fields that could be
implemented next: time, user name (I plan to do that for 2.4).
Since this supersedes date-insert, I removed Insert > Date from
the menu and propose to ditch date-insert and the corresponding rc.
The lyx2lyx reversion routine has lots of room for improvement and
attractive tasks for pythons (file timestamp, switch of localization).
Please feel invited!
This is a file format change.
* use the context language of the info inset (rather than the buffer
language), and translate strings accordingly
* for menu and shortcuts, use the Gui language instead
* actually care that all translatable strings end in po
(this wasn't the case).
Fixes: #5348, rest of #10463
Following a request by Günter, we consider the document fonts (only rm
for now) when selecting an appropriate font encoding.
See #9741
The new default font encoding setting "auto" does
* consider the font encoding needed by the language(s), which can now
have fallback alternatives
* Consider which font encoding is provided by the document font
Thus, cm now will result in OT1 fontenc, if the language can deal with
that.
The font_enc pref is ditched: it is no longer needed.
The automatism is still very basic and is subject to extension.
File format and prefs format change.
Add a new tag HasGuiSupport to language file. Add it for all l10ns
that we currently ship. The po files that are unused are not currently
tagged as available, but this could be done, since the code later
checks that the translation is actually there.
This new information is used in GuiPrefs when populating the language
combox.
The new scheme implies that adding a new language is now a two-step
process:
* the language code has to be added to po/LINGUAS, as before;
* one of the entries of the lib/language file has to be selected as
reference and be given the "HasGuiSupport true" property.
Read-only access to these classes is now threadsafe, with one exception:
The encoding neds to be already initialized (i.e. init() must not be called).
This makes bug 9336 unreproducable on my machine, although it is not completely
fixed yet.
Since a complete solution requires some refactoring, I fixed the bug for the
most important case: The main document language is only supported by
polyglossia. If any other language than the main one is only supported by
polyglossia the bug is still there.
The previous scheme of loading all possible translations and checking
whether the work is a bit too much "brute force" and causes problems
on Mac OS X (documents loaded with the wrong language).
Now there is an helper static method in Messages class that checks
whether a readable .mo file exist for the language. There should be an
API in gettext for doing that, but alas it is not possible.
As a consequence the method Language::translated() has been removed,
along with its cache.
The previous scheme of loading all possible translations and checking whether the work
is a bit too much "brute force" and causes problems on Mac OS X (documents loaded
with the wrong language).
In the new scheme, autotools install a file lib/installed_translations that contains a list of installed languages (the .gmo files that got installed). This file is read
in Languages::readInstalledTranslations and allows to set the translated() property
of each language.
exported documents.
To update the translations from the .po files, run
make ../lib/layouttranslations
from po.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38016 a592a061-630c-0410-9148-cb99ea01b6c8
This allows us to remove some ugly hardcoding of languages in the source.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36292 a592a061-630c-0410-9148-cb99ea01b6c8
- new member internalFontEncoding() that indicates if a language
switches the font encoding internally.
* src/Paragraph.cpp (latexSpecialChar):
- don't call latexSpecialT1 if the internal font encoding isn't T1.
This fixes the output of straight quotation marks in Hebrew and Greek.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27660 a592a061-630c-0410-9148-cb99ea01b6c8
- many simplification all over the place.
- improvement to the "Immediate apply" feature.
AFAICS all functionality is restored but please test and report.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@24661 a592a061-630c-0410-9148-cb99ea01b6c8
