I'm working on a FOSS project at http://unicode.codeplex.com. In this project we try to collect some information about standard keyboardlayouts.
What we want to know is there a place or document or ... which mention what's the Standard Keyboard Layout for exact language.
I mean if you are a German or American or Arab or ... , what's the standard keyboard layout in your country?
As you know there are too many layouts for each country but (in most countries) the Standard Organization of each country provide a standard layout for keyboard and all of the people should use it to prevent characters inelegance.
So if you know a document or just know your country (or some countries) standard keyboard layout please complete these information, or what else you think may help.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Standard xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Item Country="Iran" KeyboardLayout="ISIRI 9147" StandardDate="2004/09" License="Gratis" Producer="ISIRI" ProjectURL="http://sourceforge.net/projects/farsitools/" Referer="Nasser Hajloo" RefererMail="n.hajloo#gmail.com" />
</Standard>
Each Item provided for each country and here is the attribute description
Country = Country name
KeyboardLayout = the name of standard keyboard layout
standarddate = when this layout was standarded
License = what's the keyboard layout license. if you do not know leave it blank
Producer = the name of standard organization
projectURL = if the project is available on the web and is published by the producer, where is it? if you do not know leave it blank
Referer = Your Full Name
RefererMail = Your email
Related
I need help for Magento 2.x shipping Address fields.
I want to change the Address label text using my new Label text.
Is there anyone you who have changed the Address Label text by own Lable Text. Could anyone please give the file path and where I can change the text for Checkout page Shipping address fields.
Please Take a look my screenshot below.
Here is the path where you can edit Address label text:
app/code/Magento/Checkout/view/frontend/layout/checkout_index_index.xml
Following will be helpful
step 1 :
If you want to change the shipping address fields as well as billing address fields, You can do via theme transaction if you have made a custom theme as per your language.
i.e: en_US
Step 2 :
If you change made in shipping address fields only, Please override LayoutProcessor.php
step 2.1
di.xml
path: app/code/vendor/module_name/etc
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
<type name="Magento\Checkout\Block\Checkout\LayoutProcessor">
<plugin name="Custom_Checkout" type="vendor\module_name\Block\LayoutProcessor" sortOrder="100"/>
</type>
</config>
Step 2:
LayoutProcessor.php
path:app/code/vendor/module_name/Block/
public function afterProcess(
\Magento\Checkout\Block\Checkout\LayoutProcessor $subject,
array $jsLayout
) {
$jsLayout['components']['checkout']['children']['steps']['children']['shipping-step']
['children']['shippingAddress']['children']['shipping-address-fieldset']['children']['lastname']['label'] = __('Recipient lastname');
$jsLayout['components']['checkout']['children']['steps']['children']['shipping-step']
['children']['shippingAddress']['children']['shipping-address-fieldset']['children']['region_id']['label'] = __('Division');
return $jsLayout;
}
}
It's work like charm
I know this has been asked before, but I seem to be going around in circles
Where in the magento file structure is the HTML file that displays amongst other things Anashrias Sandals(as well as Magentos end of summer sale etc...)
Ive installed the sample application to Magento CE V1.7.0.2
I can see the definition in Magento/Admin under CMS->Pages->Home Page->2 Columns with Left Bar, but Ive wondered all through the file system. The PHTML specifies the familiar
echo $this->getChildHtml('content')
But I cant seem to find anything that 'content' could resolve to that display Anashrias graceful feet and sandals
Content.phtml simply states
getPageContent(); ?>
Arghhhhhhh
Even turning debugging on puts dashed red lines around every block EXCEPT the content page
Sadly those wonderfully manicured toes must go
...but how
I was going to just comment, but to explain thoroughly I need more space ;)
To answer your comment directly, the content you see isn't necessarily in a file somewhere, the "content" for CMS pages are within your database. By changing the content field on your CMS Page (Magento Admin -> CMS -> Pages -> select a page from the list), you can change the center content for that page. Magento has many different page "types" (Each Parent of the tags in xml (explained later) is a layout handle signifying a page type), common examples are cms, category, product, checkout, cart, customer account, etc.
So, when you see $this->getChildHtml('content');, what you see is a call to the system to pull the child block named "content" from the XML. This changes depending on what page you are on, as dictated by the XML and Magento Core Code.
Layout Files
Lets take a look at the source of where the name "content" comes from. Our current working directory is /app/design/frontend/base/default/layout/. In this folder you will see a list of .xml files, these are the files that dictate how a page is put together. The block named "content" is originally defined in page.xml at around line 91:
<block type="core/text_list" name="content" as="content" translate="label">
<label>Main Content Area</label>
</block>
Also, note that this section is "nested" in the <default></default> tags. Those tags are the layout handles I was talking about, and this shows that all pages should be loaded with this xml layout by default. So here is our "content" block, in all its glory. It's actually just a namespace. The other layout pages will each load what they need from within the content block.
Now, let's look at another relevant layout file, cms.xml, around line 45:
<cms_page translate="label">
<label>CMS Pages (All)</label>
<reference name="content">
<block type="core/template" name="page_content_heading" template="cms/content_heading.phtml"/>
<block type="page/html_wrapper" name="cms.wrapper" translate="label">
<label>CMS Content Wrapper</label>
<action method="setElementClass"><value>std</value></action>
<block type="cms/page" name="cms_page"/>
</block>
</reference>
</cms_page>
Here, the <reference name="content"> denotes that everything nested here is a child of the "content" block. We don't need to call it like <block name="content"/> because we know it was already defined in page.xml.
From there, they have the "cms.wrapper" block, which basically just sets the div that "wraps" around the rest of the cms content. Nested within the wrapper is our <block type="cms/page" name="cms_page"/>. This is the bad boy that outsources our template job to the cms/page block class, located in app/code/core/Mage/cms/page.php. From there, basically the class will grab our CMS Page detail from the database and present it for all to see.
So, to answer your question in short, there is no file that has the content of the cms pages, it is pulled from the database and generated upon page request.
Block Tag Explained
Blocks have various attributes to it, I'll go over the basics.
type="core/template": The type denotes what kind of block class it is. This refers to the folders nested in the "app/code/core/Mage/" folder (typically, with exceptions*). Here we are referring to app/code/core/Mage/Core/Block/Template.php. The class you set here will be attached to your template. This is responsible for the prolific use of $this->doSomething() in your template files. Basically the template file is calling the class object to do the work. "core/template" is a good general use class to fall back on when adding custom template files, although in certain circumstances you may need to choose something else.
name="content": Here we are giving our block a name. It would be the identifying name of the block, and it's used to reference that block everywhere. The block name is needed for such things as xml references (<reference name="blockName">) and to call blocks from within parent phtml template files (<?php echo $this->getChildHtml('blockName'); ?>). Note that all templates which call it without an argument ($this->getChildHtml('');) means to call ALL child blocks without being explicitly called.
as="content": This signifies an alias identifier. You can use the alias the same as the name above.
template="page/html/callouts.phtml": This sets the template for the block. Magento will look for app/design/frontend/your_package/your_theme/template/page/html/callouts.phtml and use it as the block's layout.
*Exceptions: Third-party extensions typically use either app/code/community or app/code/local folders. If you have to overwrite a core class, copy the directory structure to the local folder and then make your edits to the local version of the class.The classes load in this order: /local/ > /community/ > /core/. If a local version is found it will use that first, followed by community and core, and takes the first class file found with that name.
local.xml
Let me introduce you to the proper way of modifying your layout. Here, create a file called local.xml in your directory app/design/frontend/your_package/your_theme/layout/. This one file will house all your layout updates, to prevent any conflicts that may arise if you start editing the base layouts. Also, it keeps all your custom changes in one tidy file.
We'll remove some things that the demo store puts in that isn't really needed. Your layout should look like this, to start:
<?xml version="1.0"?>
<layout version="0.1.0">
<!-- Layout Handle -->
<default>
<!-- Block Reference -->
<reference name="left">
<!-- Remove by Reference Name -->
<remove name="left.permanent.callout"/>
</reference>
<reference name="right">
<remove name="right.permanent.callout"/>
</reference>
</default>
</layout>
Not a whole lot there, but what this will do is remove the callout ads on the left and right side bars. You'll need to refresh your cache upon making layout xml changes.
Read another one of my answers for some more things you can do with local.xml:
Magento Sidebar Customization
Edit 08/16/13:
I glossed over the Magento Design Guide (I had it once, good resource to start off, but by the first time I read it I already had learned everything it had to offer). The fallback structure it speaks of is in regarding the code/template/layout/skin/translation files.
The packages to use are partially set by you, in System->Configuration->Design. If it is not found, then it falls back to default. If default doesn't have what it's looking for, it grabs the base file. Magento does this inherently by design.
Unfortunately I don't see any built in mechanism for falling back database content. The cms content is made up of 4 tables, cms_block, cms_block_store, cms_page and cms_page_store. cms_block_store and cms_page_store each only contain the page/block id and the store id. both ids are primary keys. This is to relate the page/block id to which store it belongs to.
I suppose you could try to instigate a fallback for cms content by having it search for that page with store id, and if not, fall back to the same page ID from a different store. Or perhaps make a "base" store record that is only used as the fallback store id. I wouldn't be sure exactly how to implement either one though.
For your reference these are the cms_block and cms_page tables:
cms_block Table
[block_id] //Internal Id, Auto Increments and is Primary Key
[title] //Block Title as User Defined
[identifier] //Block Identifier, also User Defined
[content] //Block Content Stored Here
[creation_time] //Date-Time the Block was Created (ex. 2013-07-22 17:21:18)
[update_time] //Date-Time the Block was Last Updated
[is_active] //Show(1) or Hide(0) Block.
cms_page Table
[page_id] //Internal Id, Auto Increment, Primary Key
[title] //Page Title
[root_template] //Template Layout (one_column, two_columns_left, etc)
[meta_keywords] //Meta Keywords
[meta_description] //Meta Description
[identifier] //User Defined Page Identifier
[content_heading] //Content Heading to be Displayed
[content] //Page Content
[creation_time] //Date-Time Page Created
[update_time] //Date-Time Page Last Updated
[is_active] //Show(1) or Hide(0) Page (0 = 404 error)
[sort_order] //Legacy(?) Page Sorting Order**
[layout_update_xml] //XML Layout Changes***
[custom_theme] //Override Page w/ Different Theme
[custom_root_template] //Override Page w/ Different Layout than Set Above
[custom_layout_update_xml] //Override Page Layout w/ Different XML***
[custom_theme_from] //Set Date to Start Overriding Page w/ Custom Layout
[custom_theme_to] //Set Date to End Overriding Page w/ Custom Layout
/*
/**I don't see anywhere to set via Admin Back-End. All mine are set to (0),
/ my best guess is it was used to sort page link order in a menu. Either
/ they removed this feature somewhere along the way or I somehow removed
/ it and forgot.
/
/***Think local.xml without the need to use the layout handle. In other words:
/ You can modify specific pages with the same xml styling as used between
/ the <default></default> tags above. Don't actually put <?xml>, <layout>
/ or <default> (the update handle) tags.
*/
So that's all that is in the cms portion of the database.
Fallback
When properly configured, Magento will fall back in this order:
<!-- Front End Package/Theme Template and Layout Files -->
app/design/frontend/yourPackage/yourTheme/
app/design/frontend/yourPackage/default/
app/design/frontend/default/default/
app/design/frontend/base/default/
<!-- Admin Package/Theme Template and Layout Files -->
app/design/adminhtml/yourPackage/yourTheme/
app/design/adminhtml/yourPackage/default/
app/design/adminhtml/default/default/
<!-- Front End Package/Theme Skin (JS/CSS/Images) Files -->
skin/frontend/yourPackage/yourTheme/
skin/frontend/yourPackage/default/
skin/frontend/default/default/
skin/frontend/base/default/
<!-- Admin Package/Theme Skin (JS/CSS/Images) Files -->
skin/adminhtml/yourPackage/yourTheme/
skin/adminhtml/yourPackage/default/
skin/adminhtml/default/default/
<!-- Magento Code Pool -->
app/code/local/**
app/code/community/***
app/code/core/
/*
/**Magento will, by default, only look within local folders that currently
/ exist in the core directory, community directory*** OR if an active
/ module has codePool*** set to local.
/
/***Third-Party modules have to set which codePool they are using, which
/ specifies the default working directory for that module's code.
/ This is defined in the xml located at /app/etc/modules/*. If a module
/ has its codepool set to community, you can override the extension's
/ code by copying it to local.
/*
The "community" codePool is said to be there for legacy reasons, and that new extensions should be made to use the "local" only. I personally don't agree, it would make much more sense for every Third-Party extension to use the community codePool and retain the ability to override the original extension code from "local" without modifying the original.
Okay, I think I'm done with this question, as any more information here would be overload. If I missed anything, start a new question and link me to it ;D.
The subjectScheme in DITA is a suitable format for creating a taxonomy of metadata, but how should it really be used? Specifically, my question regards the following:
Can it be used to represent metadata elements, or only metadata attributes? I've only seen it applied to attributes, which makes it kind of limited, since as far as I know elements are usually used for retrieval metada, i.e. not metadata used for filtering.
If you could use it for elements, should the value still be in the "keys" attribute of the subjectdef?
If you want to add a definition/description to a metadata value, where would you do that?
Can/should you publish subjectSchemes? I've seen it suggested that it is not intended for publishing, due to its resource-only default attribute. But isn't that limiting? If you use it to create a taxonomy, surely you would also want a simple way to publish it for the benefit of the users?
I'm going to do my best to address your original questions. Overall, the subjectScheme specialization is designed to create subject classifications and controlled values. It has great functionality for defining subject classifications that can be used for retrieval, as well as defining and controlling attribute values. Currently, the DITA-OT only provides functionality in the area of controlled values for attributes.
Question: "Can it be used to represent metadata elements or only metadata attributes"?
Answer: I would not say that its purpose is to "represent elements or attributes". It is designed to represent subjects and controlled values. Its design is based on keys and so makes heavy use of attributes.
Question: If you want to add a definition for an attribute value, where do you do so?
Answer: You have several options for doing this:
You can create an associated topic that describes the subject or attribute value. You reference this topic using the #href attribute on the subjectdef element. This is especially useful for providing a consensus definition or information about when a conditional-processing value should be used.
You can nest a topicmeta element within the subjectdef element; within the topicmeta element, you have access to the shortdesc and navtitle elements.
You add content to the #navtitle attribute on the subjectdef element. I would not recommend this, as the #navtitle attribute is deprecated and usually cannot be translated.
Question: Can you use the subjectScheme specialization with metadata elements?
Answer: Yes. Off the top of my head, here is one immediate possibility and design for an HTML-based output format:
For a specific subject, add a topicmeta element to the subjectdef element. Within the topicmeta element, you have full access to all the metadata elements. Add as many metadata elements as you like.
Associate the DITA topics with the relevant subject. This can be done either by using specific attribute and values, or by using the subjectref element from the classification domain.
Tweak the output processing so that each DITA topic associated with the subject has the metadata written to the HTML, just as it would be if the metadata elements were located in the DITA topics itself. With this design, you have enforced consistency and, because of the key-based architecture, ease of maintenance and an abstraction layer.
Question: Can you publish subject schemes?
Answer: Yes, if topics are referenced for subjectdef elements using the #href attribute. While by default, the #processing-role attribute for the subjectScheme element is set to "resource-only" and the #toc attribute is set to "no," you can modify those values and they will cascade throughout the map, making it possible to generate output. Of course, this is simply what one can currently do using the DITA-OT; with custom processing implementations, the possibilities are boundless.
I think subjectScheme maps and the classification domain offer lots of exciting possibilities, including faceted and filtered browsing (for output) and faceted searching (for DITA source).
I hope that people building implementations that make use of subjectScheme and classification will share stories, demo their implementations, and so forth. I think that would make what can be done with this part of the DITA architecture clearer and more accessible for people.
As far as the DITA-OT goes, I think you can only use it for conditional processing (filtering and flagging) of elements using DITAVAL files.
I think subject scheme maps have far more potential than this. They could be used for faceted browsing so we could dispense with static topic maps. Static content just seems to belong to the pre-web era. DITA's slightly staid aura could be solved with this.
Anyway, here's what you can currently do:
Subject scheme map:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE subjectScheme PUBLIC "-//OASIS//DTD DITA Subject Scheme Map//EN" "map.dtd">
<subjectScheme>
<hasInstance>
<subjectdef keys="all_routes">
<subjectdef keys="every_route">
<subjectdef keys="anglia"/>
<subjectdef keys="east_midlands"/>
<subjectdef keys="kent"/>
<subjectdef keys="lne_london_north_eastern"/>
<subjectdef keys="lnw_london_north_western"/>
<subjectdef keys="scotland"/>
<subjectdef keys="wales"/>
<subjectdef keys="sussex"/>
<subjectdef keys="wessex"/>
<subjectdef keys="western"/>
</subjectdef>
</subjectdef>
</hasInstance>
<enumerationdef>
<attributedef name="route"/>
<!-- Above is my new specialized attribute "routes"! -->
<subjectdef keyref="all_routes"/>
</enumerationdef>
Here is the topic text with the metadata:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA General Task//EN" "task.dtd">
<task id="task_ozd_ckn_qh">
<title>Route specialization test</title>
<shortdesc route="">This tests the new route attribute!</shortdesc>
<taskbody>
<section>
<title>Lines of text</title>
<p route="anglia">Anglia text text text text text text.</p>
<p route="sussex">Sussex text text text text text text.</p>
<p route="east_midlands">East Midlands text text text text text.</p>
<p route="kent">Kent text text text text text text.</p>
<p route="lne_london_north_eastern"NE text text text text text text.</p>
<p route="lnw_london_north_western">LNW text text text text text text.</p>
<p route="scotland">Scotland text text text text text text.</p>
<p route="sussex"Sussex text text text text text text.</p>
<p route="wales">Wales text text text text text text.</p>
<p route="western">Western text text text text text text.</p>
<p route="wessex">Wessex text text text text text text.</p>
<p route="every_route">Text.</p>
<p>Not profiled.</p>
</section>
</taskbody>
Here's the DITAVAL filter:
<prop action="exclude" att="route"/>
<prop action="include" att="route" val="scotland"/>
This will knock out all the other routes except the route marked with "scotland".
That's basically it.
You can add metadata into the subject scheme map like this:
<subjectdef keys="story_attributedef">
<subjectdef keys="monster">
<hasKind>
<subjectdef keys="zarbi" href="glossary/contemporary.dita">
<topicmeta>
<navtitle>The Zarbi</navtitle>
<shortdesc>Ant-like creature</shortdesc>
</topicmeta>
</subjectdef>
Subject scheme maps are rendered as "resource-only" (whether they have that value or not) so it's not suitable for rendering.
Currently I try to fix a issue on our SocialEngine installation (which is built on Zend) which shows in the language selector one language not in its native name (like "Deutsch" for "German") but in the language the user has set the frontend (so instead of "Deutsch" you would see "German" when you set the language to English).
When looking in the source I've seen that Zend_Locale_Data loads a list of languages which are available for the system and tries to read a LDML file from a path which seems not to be on my machine:
$temp = self::_getFile($locale, '/ldml/localeDisplayNames/languages/language', 'type');
When the path is not on my computer, it has to be in the web but doing a search for "ldml" or "zend ldml" I don't get any hint on this topic. Could you guide me through the fog?
Any help is appreciated. Thank you!
The '/ldml/localeDisplayNames/languages/language' that you see is not a file path but a XPath expression, the file that is read is an XML file located in Zend/Locale/Data/ and the filename is related to the given $locale parameter.
e.g. For the english locale, the XML file loaded should be Zend/Locale/Data/en.xml. Opening this file will show you the structure selected by the XPath expression
<?xml version="1.0" encoding="UTF-8" ?>
<ldml>
<!-- content skipped -->
<localeDisplayNames>
<!-- content skipped -->
<languages>
<language type="aa">Afar</language>
<language type="ab">Abkhazian</language>
<!-- etc... -->
Can anyone please give me an idea on how to autocomplete input controls in XForms such that when a user begins typing words that begin that way appear?
Also how can I populate a control from the value of another control? Like in a drop down menu when a user selects a country name, the next field is automatically populated with that country's capital.
Country: Egypt
City: Cairo (City should appear automatically)
XForms itself does not provide autocomplete functionality, but Orbeon Forms implements such a control with XBL and JavaScript. Here is the documentation.
The control has multiple modes, but you typically use it this way:
<fr:autocomplete ref="country-name" dynamic-itemset="false">
<xforms:label>Enter a country name: </xforms:label>
<xforms:itemset nodeset="instance('all-countries')/country">
<xforms:label ref="name"/>
<xforms:value ref="name"/>
</xforms:itemset>
</fr:autocomplete>